Snowie 4 7 1 Serial Port

Would this apply to any machine using the Stentura protocol? Frankly, the whole serial cable/USB thing has been giving me a bit of a headache. I'm trying to get a handle on it. For instance, the 'Wave student writer' that I got has a port on the back that says 'USB' on the back. The cable that I got with it purports to be a 'Serial to USB' cord that it came with plugs into the back of the machine and goes into the USB port on a computer. Can I also expect a 'normal' serial cable to work with this puppy?

There's precious little explanation on the stenograph website. I'd like to get down and dirty with Plover, preferably on my Macbook, and dump my infernal Windows laptop. G Hesky Fisher 4.11.12. Hello Hien, It would be simpler to manufacture if you replaced the discrete components of the keyboard with a CPLD or FPGA. If you do not need a display your can replace the Raspberry PI with an Atmel AT32UC3A3256 microcontroller with a USB port. A SD card to store the dictionary with the microcontroller firmware updated via the USB port. With forward looking board design you can have the microcontroller run either your custom keyboard, a standard USB keyboard or a commercial Steno machine.

I envision a palm sized board that slips between a keyboard and a PC drawing its power from the USB port. Regards, George Boudreau Toronto, Canada Hien Quan 20.11.12. This is great to see! I've been wanting to do this for a long time. I still may, but I'm glad you beat me to the punch.

Good luck and keep us posted. I'll try to pitch in when I can. I think using a Raspberry Pi is a good idea.

Cheers, Josh On Tue, 20 Nov 2012, Hien Quan wrote: >For those who are interested, I've recently committed myself to building a >USB Plover Keyboard. The goal is to prototype a steno keyboard that outputs >transcribed words, as performed by Plover, over the USB keyboard interface. >>For more info refer to my post here >>>Cheers, >Hien >Josh Lifton 20.11.12. >It would be simpler to manufacture if you replaced the discrete components >of the keyboard with a CPLD or FPGA. It would certainly be fewer discrete components, but you'd need more advanced manufacturing and testing facilities, which would put it out of reach of most hobbyists.

It may also be more expensive in the end. >If you do not need a display your can replace the Raspberry PI with an >Atmel AT32UC3A3256 microcontroller with a USB port. A SD card to store the >dictionary with the microcontroller firmware updated via the USB port. This would certainly work, but it would likely require rewriting Plover in a language other than Python. There are things like PyMite, but even that would be a bit of work. The great thing about the Raspberry Pi is that it was designed to run Python.

>With forward looking board design you can have the microcontroller run >either your custom keyboard, a standard USB keyboard or a commercial Steno >machine. I envision a palm sized board that slips between a keyboard and a >PC drawing its power from the USB port. There's certainly a lot of room for flexibility. I always find it difficult to choose which features to drop and which to keep. Cheers, Josh Gabriel Holmes 21.11.12.

CSJ 2050-03-004, ETC. SPECIAL SPECIFICATION. ROADWAY WEATHER INFORMATION SYSTEM. PRECIPITATION RATE ERROR SHALL BE LESS THAN 10% FOR THE FULL. DENSITY FLOPPY DISK DRIVE, MINIMUM 12.0 DRIVE, TWO SERIAL PORTS. TracVision M5/M7 User's Guide. Chapter 1 - Introduction. Circular and Linear Versions. Your TracVision system is configured for either circularly polarized satellite signals (North. Figure 1-4 Approximate Skew Settings for the PAS 9 Satellite. TIP: If your computer does not have a DB9 serial COM port, you can use the.

The pickup: There are two options that I considered, optical sensing, where pressing a key interrupts an infrared light beam, and capactive sensing, where pressing a key brings a small charged plate closer to the electrical ground. TI has a microcontroller where all the capacitive sensing electronics is built into the chip itself.

There is a high-value resister, and the plate is charged. As the voltage drops as the charge drains through the resister, the number of recharge cycles in 10 microseconds is counted. The key is adjusted to 'trip' when the key is 2/3 pressed, and 'untrip', when the key is 1/3 pressed (or 2/3 released). This eliminates having to deal with the 'debouncing' problem and the fact that electrical switches are noisey at the moment they close or open.

Keygen Wiso Sparbuch 2013 Corvette. With a 22-key system, this can be accomplished with some point-to-point wiring and one of the 24-input pin designs. The only other necessary component is the resister, one for each pickup. Hien Quan 21.11.12. Tiago, I'm glad someone else is paying attention!:-) Some clarification for this initial design: 1. I've been mulling over the design for the past few weeks. And wanted to 'quickly' put down in schematic the ideas that's been going around in my head. All passive components are representative only.

I wanted to make sure the logic flow is sound first. Here's how the input capture is supposed to work At power on the 'Ready' signal is low. The RasPi would poll this line and read the keys when 'Ready' is high. The debounce inputs are active low. Each input has a pull-up resistor. When one or more keys are pressed - transistor Q1 is turned on.

This in turn causes Fout to go high. The Q_ output of the flip-flop U47 is default to high - which when AND with Fout enables all the latches. I'm assuming that for chording you'd press and hold the keys in turn. As long as one key is pressed during the chord the latches will be enabled and the keys recorded. When the last key is released, the falling edge of Fout causes flip-flop U47 to change its Q_ output state to low. This then disables the latches and further key presses will not be recorded. At the same time Fout Q output goes high - therefore the 'Ready' signal is high.

RasPi would individually address each key blocks and read their state. This is achieved by enabling the output of each latch, whose output are defaulted to high-impedance when output is not enabled, which then drives U20 as an interface buffer. Each data bit represents one key and a key map based on the select1-3 bit values and bit masks for Data0-7 determines the key code. Once all key states have been read, the 'Processed' line would be toggled which then resets U47 output thus enabling the latches to be active when the next key is pressed. Some time when you've been working closely to a project for too long you lose sight of things so having someone else go over the design logic may point out glaring errors. Obrigado, Hien Tiago Daitx 22.11.12.

I've completely redesigned the circuit based around asynchronous latches. When a key is pressed its state is locked asynchronously from other keys.

There is now no need to de-bounce the switch. The process of notifying the RasPi, selecting and reading the key states and resetting the latches remain the same. The overall design uses less ICs but more resistors - which can be catered for using in-line SIP Resistor Arrays. Would appreciate some other eyeballs on the latest schematic.

Cheers, Hien Tiago Daitx 22.11.12. Tiago, This design reproduces the same ability to capture a whole chord as the previous design. So nothing lost:) I am aware of the over use of the I/O lines. Again I wanted to validate the design from a logic stand point before optimising. With this new design we could reduce the data bus to 4-bits, and use 3 select bits driving a binary-to-decimal decoder. Decimal values 1-6 would select the appropriate 4-bit blocks containing the key states.

Decimal 7 can be used as the 'Processed' signal to reset the latches. Including the 'Ready' line this means the whole thing can fit in 8-bits. I'll need 1 GPIO on the RasPi for I2C communication with the PIC Microcontroller, to send USB HID Keyboard data. So a total of 9 GPIOs are required. We can also really go to town with optimisation by using serial shift registers to reduce the data bus to 1-bit. However that would obfuscate the logical design I wanted to validate first.

Once I've fully validated this new design I'll optimise it as per the above - using 4-bit data bus. As for processing data in 1 byte of parts thereof.

You'll need to apply various 'bit masks' on the different GPIO registers. Not that difficult but you do need a clear head when designing the masks. Regards, Hien leeo 25.11.12.

I purchased (ebay) a Stentura 200, one of the last all-mechanical models made, The advancing mechanism on the paper-tape should be illustrative. Pressing any key except the 'number bar', which is a type of 'shift key', arms the paper-tape advance. It stays in the 'armed' mode until all keys are released. Thus for a stenography system, the end of a keystroke is not triggered by the space of time between keys, but by the detection of the 'all keys up' situation.

On my version of Plover, which I call 'Plugh', I specifically look for the 'all keys up' situation, and accumulate for a stroke all the keys touched during an 'any keys down' situation. This can lead to a situation called 'stacking', but more modern theories and practice modify the strokes to avoid this. On investigating the Plover alphabet, there are some 'stacked' strokes defined to help alleviate this, as well. - - - - - One additional note, I find it necessary to purposely 'stack' a key in order to get consistency.

For the -ngk sound, stroked in the theory as /*PBG, I find my fingers locking up trying to make the chord for word like 'blink' and 'blank'. I stroke 'pling', or 'blang' for this stroke, and release every key except the 'G' key, and while holding the 'G' key, I press the '*' key with the other hand. It does have a small speed penalty, but I experience no fingers locking up. --leeo Gabriel Holmes 7.12.12.