LitePlacer.com forums

Covert wrote: The solution to my problem was to disable slack calibration. That fixed the crash/halt of the TinyG.

Wow, thanks for figuring that out, I never would have guessed.

WayOutWest wrote: 1. It uses that stupid FTDI chip, they are really unreliable -- like nearly all USB-to-serial adapters, which work "just barely well enough" if you don't push too hard or ask them to do anything out of the ordinary.

Apparently the TinyG people have noticed this and dumped the FTDI chip for native USB in the next version of the board. Hooray.

In the meantime, you really should make sure to require RTS/CTS flow control ($ex=2) and refuse to allow any other setting. No flow control ($ex=0) will lead to incredibly hard-to-troubleshoot heisenbugs, and XON/XOFF flow control ($ex=1) is MUCH harder to implement correctly than people think (from some TinyG forum postings it appears TinyG did it wrong and they are aware of this).

WayOutWest wrote:

WayOutWest wrote: 1. It uses that stupid FTDI chip

In the meantime, you really should make sure to require RTS/CTS flow control ($ex=2) and refuse to allow any other setting. No flow control ($ex=0) will lead to incredibly hard-to-troubleshoot heisenbugs, and XON/XOFF flow control ($ex=1) is MUCH harder to implement correctly than people think (from some TinyG forum postings it appears TinyG did it wrong and they are aware of this).

I have to retract what I said here. TinyG's RTS/CTS is even more broken. It's not clear whether the FTDI chip or the TinyG board is at fault, but it manages to produce this lovely message on my console when I use $ex=2:
That should never, ever happen. Basically the FTDI chip sent a malformed RS232-over-USB packet.

Apparently the best you can hope for here is to use byte-counting in the Host->TinyG direction (it has a 254-character buffer, you have to keep track of how much is free by parsing the JSON responses) and XON/XOFF for the TinyG->Host direction. In this situation XON/XOFF is slightly less tricky because one side knows the exact size of the other side's RX buffer and guarantees it will never be overrun using a higher-level (in this case, JSON) protocol. So by limiting yourself to 253 characters in flight you can leave room for the XOFF. Under these assumptions XON/XOFF is pretty trivial to get right, so however the TinyG implemented it probably works.

Hello,

Maybe not related to this topic, but just to remind - at least HP laptop users - that some PCs have a default setting
of the function keys that allows (Win) to use of them without the FN key. If that is the setting, obviously many of the
jogging key commands do not work in LitePlacer due to the interference. So you need to edit the corresponding
BIOS setting to use the option where FN is required for the function keys.