which steno machines are known to work with the Plover port on Macs?

[Gabriel Holmes]

And what cables...etc etc. Any advice would be greatly appreciated.

Thanks!

[Hesky Fisher]

Right now plover supports the same machines on mac as on windows and linux:

- stentura (all modern machines by stenograph)

- gemini pr (machines from http://www.geminiwriter.com/)

- tx bolt (many machines have a mode to use this)

To use these you will need to attach your machine to the computer with a serial cable. If your computer doesn't have a serial port then you can get usb adapters. In fact, some stentura machines have a built-in serial port adapter in the USB port but I'm not sure if they provide drivers for mac.

I have used the following adapter plus a regular serial cable to connect a stentura protege to the mac: http://www.amazon.com/gp/product/B0007T27H8/ref=wms_ohs_product

It's a little annoying that it's two cables. I'm thinking of getting something like this one (http://www.usconverters.com/index.php?main_page=product_info&cPath=67&products_id=325), which would just go from the machine to the computer. But I haven't tested it yet so can't recommend it.

[Gabriel Holmes]

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]

The wave has a built-in serial port adapter. The problem is that I don't know if there are any drivers for it for the mac. I was unable to find one with simple googling...

[Gabriel Holmes]

But what does that mean? Will a plain old "serial cable" go into it? And then I can combine it with the adapter of the sort that you mentioned?

Or am I SOL on this?

Thanks...

[Hesky Fisher]

I don't have a wave so I am not 100% sure but the pictures I see on the web don't show a serial port, just a USB port. 

So, unless stentura (or someone else) makes a driver for the mac then it won't be usable. Sorry about that.

[Gabriel Holmes]

Commence loss mitigation mode...

Thanks for the straight answer.

[theszak]

What about this Diamante?...
at
http://stenograph.com/category.aspx?id=100001&subid=6140001

[Mirabai Knight]

I'm not sure whether the Diamante employs Stentura protocol or not. My guess is not. :(

[Gabriel Holmes]

Ludicrously out of my price range.

[Gabriel Holmes]

[Gabriel Holmes]

I'll see if I can trade in my Wave for a Stentura Protege with Stenoworks.

Thankfully, my union paid for the theory class, and I'm not matriculated, and I have a day job.

Thanks for all the help!

On Sunday, November 4, 2012 2:30:20 PM UTC-5, Gabriel Holmes wrote:

[Hesky Fisher]

The diamante does use the stentura protocol via the virtual serial port over USB. This means that it is compatible with plover. But not on mac or linux, unless there are drivers that I haven't found.

[Mirabai Knight]

What about via Bluetooth? Since it seems like Bluetooth communicates to steno machines via virtual serial port.

[Hesky Fisher]

I suppose it might work.

[Gabriel Holmes]

Will the Infinity work? With a serial cable??

[Mirabai Knight]

Infinity definitely works -- USB, serial, and Bluetooth. (':

--
Mirabai Knight, CCP, RPR, CBC
StenoKnight CART Services
917 576 4989
m...@stenoknight.com
http://stenoknight.com

[Gabriel Holmes]

Cool. Thanks!

[Gabriel Holmes]

Can anyone tell me whether this one will work? I can't find any reference to the protocol that it uses....

http://www.acculaw.com/gemini-writer.aspx

Thanks

[Mirabai Knight]

Yep, that'll work, whether it's Gemini TX or Gemini PR (could be either, depending; there's an internal jumper that lets you switch back and forth.). Plover supports both.

[Gabriel Holmes]

The sales rep told me it was TX. So this should work with my macbook (Mountain Lion)? Just want to make sure before I do the trade.

[Hien Quan]

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
https://plus.google.com/102978357948570523906/posts/ZUEaRbfxaHF

Cheers,
Hien

[George Boudreau]

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]

Hi George,

Thanks for your input :-)

My idea is to quickly prototype a keyboard that builds on Plover. Design for manufacture and cost reduction is not a consideration at the moment since I have limited time to dedicate to the project. I also don't want to reinvent the great work that's gone into Plover.

Regards,
Hien

[Josh Lifton]

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

[Josh Lifton]

> 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]

I wonder what role 3D printing is going to play in all of this....

[leeo]

I have also investigated this -- open source design, and open source component manufacture.  I have been researching this until I decided to get back to my traditional stenography study for the time being.  Here's what I came up with: 

 

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.  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]

Thanks Leeo for your input. Some interesting ideas for the input side.
Not having typed on a real steno keyboard I have to ask about the tactile feedback from such keyboards. Also how quiet are the real steno keyboards?

For the moment I intend to use micro lever switches. This would allow me to shorten or lengthen the arms that the keys sit on.

Optimisation of the keyboard would come at a later date.

Cheers,
Hien

[Hien Quan]

Josh, thanks for a motivating email. I've already purchased the Raspberry Pi and PIC microcontroller dev kit several months ago. The main hurdle at the start of any project is procrastination. To overcome this I decided to publicly commit to the project thereby tipping the scale toward taking action.

I'll keep the group updated with my progress.

Cheers,
Hien

[Tiago Stürmer Daitx]

Hien,

I looked over the schematics and the datasheet for those ICs. I got the overall idea on how the latch is supposed to help capture all pressed keys together but when I try to follow up the circuit logic I can't see how it's going to do it... I believe my (very rusted) electronics skill is failing me.

I assume the "processed" input is going to be HIGH most of the time - ie. whenever Raspberry Pi is not reading the (selected) key states - and that U12's Fout is going to be HIGH when no key is pressed.

So, whenever the first key in the chord is pressed it should go like:

1. U12's Fout is set to LOW

2. The latches LE port is also going to go LOW (preserving the input) due to the AND port

3. Due to the HIGH-LOW transition the flip flop will set the "ready" output (Q) to HIGH

4. After detecting that "ready" is HIGH the Raspberry Pi will set "processed" to LOW

5. Raspberry Pi will ready each latch by "select"ing them

6. Raspberry Pi sets "processed" to HIGH again

If that logic is correct it seems that only keys pressed /very/ shortly together will be available at the latches. Also, there seems to be no way to "adjust" the delay window between the first and last key press that will be detected as a chord. Did I miss(understood) something or is that expected?

BTW, C1 to C4 value seem to be wrong. According to the MC14490 datasheet it should be 100 pF  or higher but the schematics say 1 pF.

Regards,

-Tiago

--
Tiago Sturmer Daitx
tda...@gmail.com

[Hien Quan]

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.
2. 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 Stürmer Daitx]

Hien,

Thanks! From your explanation I see that I confused how MC14490 input/output level were supposed to work. By reading the section "THEORY OF OPERATION" and looking at figure 3 of it's datasheet (http://www.onsemi.com/pub_link/Collateral/MC14490-D.PDF) I previously assumed levels would be LOW when a key was pressed.

Now it makes more sense. As long as all keys are released closely together the logic will work as expected but... I still wonder how closely that will have to be. 

Given that:

- only the last key will be able to change flip flop U47 output, and

- all key signals take the same amount of time to be processed

it seems to me that all other keys in the chord will be already LOW at the time the last one changes state. If that's true, how will the latches save the proper chord state? On a perfect digital circuit all keys would have to be released together in order to hold the chord state. I wonder if signal timing gets into play here.

Regards,

Tiago

ps.: almost missed that "obrigado" at the end, nice touch =)

[Hien Quan]

Tiago,

I knew it! I was right about "...working closely to a project for too long you lose sight...point out glaring errors."

Yes you are right about timing issues since the latch works for synchronous input. It never crossed my mind. I'll have to revise the design.

Cheers,
Hien

[Hien Quan]

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 Stürmer Daitx]

I did like the idea of capturing the whole chord and outputting that directly to Raspberry Pi, I'm sad it didn't work out.

Anyway, the new schematic is pretty neat.

OTOH, why 8 data lines and 3 select lines? That configuration requires 13 GPIO lines: 1 for READY, 1 for PROCESSED, 3 for SELECT, and 8 for DATA. By grouping in 2 blocks of 11 data lines one would need 15 GPIO:  1 for READY, 1 for PROCESSED, 2 for SELECT, and 11 for DATA. The Raspberry Pi has 17 GPIO (15 on boot). I don't know how much easier it is to program the Raspberry Pi when all data fits nicely inside 1 byte instead of a bit less than 2 bytes (11 bits).

Regards,

Tiago

[Hien Quan]

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]

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]

Can the Stentura 200SRT work with Plover+Mac?

[Hesky Fisher]

I think it would. But I can't know for sure without having one to test.

The requirement is that it use the stentura protocol and have a real serial port (not just usb).

[Mirabai Knight]

Yeah, a 200SRT is a serial-only manual machine with electronic outputs. It should work with Plover, though having written on one, I'll tell you that it takes a lot of finger strength to press the keys; more like a typewriter than a computer keyboard kind of feel.

[Joe Leone]

On Sunday, November 4, 2012 12:56:18 PM UTC-5, Mirabai Knight wrote:

I'm not sure whether the Diamante employs Stentura protocol or not. My guess is not. :(

The Diamante is based on the stentura protocol so it should work  I think 

[Snowy Wilderness]

Ooo, I have a Diamante! Can someone direct me to the Plover documentation on how to get my machine working with it...ideally on a Mac!

--

Yours Truly,

Johnny Sagan aka Snowy Wilderness

[Hesky Fisher]

Plover only supports the stentura protocol over serial port. It does not support the stentura USB protocol.

This means that plover works with:

1) stentura machines that have a physical serial port (e.g. the protege)

2) stentura machines that have a USB port that implements a virtual serial port (e.g. the diamante)

However, for option 2 to work you need to have the USB drivers installed. This is where the problem comes in. I don't know of any Mac drivers for the Diamante.

On windows, you would need to:

1) install the drivers

2) connect diamante to computer with USB

2) run plover

3) in settings choose the virtual serial port (probably the only one in the drop down list)

4) restart plover.

At this point plover should be working with the diamante.

[Snowy Wilderness]

Thank you, Hesky! Any idea what the going rate is for those ultra-populist ultralight Acer-style netbooks these days? I'd spend up to $200 to have a special little computer specially dedicated to Plover...although then I'd be tempted to run Plover on Ubuntu on it so that I could use the amazing Plover teaching game that has so far been developed only for Ubuntu! So do you know if there are Ubuntu drivers for the Diamante? Probably not...#BigSteno!

[Eve Surfing]

Hi guys,

I use Linux and I have a wave machine (USB port, not implementing a virtual serial port). Do you think I can use a adapter such as this one :
https://microbytes.com/accessories/cables/adapter-usb-to-serial9-m-trendnet-tu-s9.html
(Trendnet tu-s9).
My old computer as a serial port.

Thank you for your advices.
Eve

[Ted Morin]

Plover can only communicate with the serial on the machine, I think. Maybe a Wave owner could chime in?

--
You received this message because you are subscribed to the Google Groups "Plover" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ploversteno+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Logan]

A Mac client would be awesome. But I might as well point out that Parallels +  Cohesive mode is pretty awesome so long as you have enough space and enough memory. It can use USB devices, and with some changes to the network interface settings, you can connect with devices on the network as a distinct computer on the network taking place of the MacOS on the network by bridging to the Lan/WLAN.

It'd be great to see a native Mac app and a made for Mac device.

Best of luck!

[Ted Morin]

Plover works on Mac.

Once I get Stenograph USB working it will work directly with Mac/Windows/Linux with minimal configuration. For now the serial to USB adapters work well enough and most are cross platform.

--

[workpj]

I am, sadly, not a computer geek, but I am a CSR that loved Plover -- while it worked with my Smartwriter....but then, months into using it, suddenly, things went south.  The steno machine just stopped talking with the computer.  Glen and others tried valiantly to brainstorm why.  No solution was found.  I was on Windows XP at the time, and I got one recommended by someone on Plover site (it's been a while...), a Tripp-lite Keyspan USA 19HS

Anyway, now I have Windows 7 on a newer computer, and I'm thinking of resurrecting my efforts to use Plover.  I'm retired from court reporting, but once a stenographer, always a stenographer (I can think in shorthand when I watch movies. :>)  So...anyway, I am wondering if maybe that problem I experienced might be related to needing a different adapter cable...and this site explains why some work for some operating systems, some don't.  

http://www.usconverters.com/usb-rs232-adapter-xs8801

On Sunday, November 4, 2012 at 6:59:20 AM UTC-8, Hesky Fisher wrote:

Right now plover supports the same machines on mac as on windows and linux:

- stentura (all modern machines by stenograph)

- gemini pr (machines from http://www.geminiwriter.com/)

- tx bolt (many machines have a mode to use this)

To use these you will need to attach your machine to the computer with a serial cable. If your computer doesn't have a serial port then you can get usb adapters. In fact, some stentura machines have a built-in serial port adapter in the USB port but I'm not sure if they provide drivers for mac.

I have used the following adapter plus a regular serial cable to connect a stentura protege to the mac: http://www.amazon.com/gp/product/B0007T27H8/ref=wms_ohs_product

It's a little annoying that it's two cables. I'm thinking of getting something like this one (http://www.usconverters.com/index.php?main_page=product_info&cPath=67&products_id=325), which would just go from the machine to the computer. But I haven't tested it yet so can't recommend it.

On Sun, Nov 4, 2012 at 7:50 AM, Gabriel Holmes <holm...@gmail.com> wrote:

And what cables...etc etc. Any advice would be greatly appreciated.

Thanks!

On Sunday, November 4, 2012 at 6:59:20 AM UTC-8, Hesky Fisher wrote:

Right now plover supports the same machines on mac as on windows and linux:

- stentura (all modern machines by stenograph)

- gemini pr (machines from http://www.geminiwriter.com/)

- tx bolt (many machines have a mode to use this)

To use these you will need to attach your machine to the computer with a serial cable. If your computer doesn't have a serial port then you can get usb adapters. In fact, some stentura machines have a built-in serial port adapter in the USB port but I'm not sure if they provide drivers for mac.

I have used the following adapter plus a regular serial cable to connect a stentura protege to the mac: http://www.amazon.com/gp/product/B0007T27H8/ref=wms_ohs_product

It's a little annoying that it's two cables. I'm thinking of getting something like this one (http://www.usconverters.com/index.php?main_page=product_info&cPath=67&products_id=325), which would just go from the machine to the computer. But I haven't tested it yet so can't recommend it.

On Sun, Nov 4, 2012 at 7:50 AM, Gabriel Holmes <holm...@gmail.com> wrote:

And what cables...etc etc. Any advice would be greatly appreciated.

Thanks!

[workpj]

Hi, Hesky!

Did you ever find out if this works well?  I'm trying to get Plover and a Smartwriter to talk regularly.

http://www.usconverters.com/index.php?main_page=product_

I was using this one:  Tripp-Lite Keyspan USA 19HS with no problems....and then, for some reasons, my Smartwriter stopped interfacing with my Plover and I could never get past it in troubleshooting attempts and emails back and forth with folks in Plover group -- Glen, you, maybe others, as I recall.  I'm wondering if it could have something to do with needing a different converter. 

Now I'm on a different Windows computer with Windows 7, and I'm thinking of trying again, downloading latest Plover version, etc.  It's been a few years, but I really liked Plover and would love to be able to use Plover ongoing for occasional transcription, etc.  I was googling and saw your comments on the USB/Serial converters, and thought I'd ask the question I've posed above.  

Thanks!  Paula Joy

workpa...@gmail.com

[Hesky Fisher]

Hi Paula,

I did end up trying that converter and it worked well for me. Best of luck!

Hesky

[Glen Warner]

Hi, Paula Joy! I was wondering what happened with you.

I still use my KeySpan/TrippLite USB-serial adapter on my Mac with absolutely no issues.

I'm fairly sure I recommended this before, but it might be good for you to find someone with a different writer and see if you can get that writer to work with your setup and Plover. That way, you'll know for sure whether it's your writer or your cables.

Good luck!

--gdw