Eggtimer Windows 11 dongle problems

[Zbench]

Anyone else having issues getting the Windows 11 Dongle to work? Installed the driver and mapped the pins correctly but can’t get it to connect to anything. I can see it in the terminal program but it will not stream GPS data or connect to an altimeter to recover the gateway passkey.

Have tried on a Quasar and several Quantums. Thought I would check here before contacting Cris directly in case other are having the same
issue.

 

[Worsaer]

One suggestion to narrow down the issue. Bridge the transmit and receive pins instead of connecting to a device. Then, in Putty, or another tool, you should see what you type echoed to your screen.

 

[Kallahan11]

In Teraterm I believe I had to add flow control Xon Xoff to get it to work.

 

[Zbench]

Great suggestions. It does parrot back typed data but none of the settings allow a connection to any of my devices. I can connect to them via the old cable and an ancient laptop.

 

[cerving]

Did you install the VCP driver from the Silicon Labs site, or did you use the one that Windows has built-in? If it's the latter, go to https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers to install the proper driver. The built-in Windows USB-Serial drivers don't seem to work... this is an old issue, I first ran into it about 20 years ago with a piece of diagnostic equipment that used a Prolific chip but the SiLabs drivers in Windows aren't any better.

Also, you need to turn off flow control in Putty to get it to transmit data. Do NOT use XON/XOFF or "hardware" flow control.

 

[Zbench]

Did you install the VCP driver from the Silicon Labs site, or did you use the one that Windows has built-in? If it's the latter, go to https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers to install the proper driver. The built-in Windows USB-Serial drivers don't seem to work... this is an old issue, I first ran into it about 20 years ago with a piece of diagnostic equipment that used a Prolific chip but the SiLabs drivers in Windows aren't any better.

Also, you need to turn off flow control in Putty to get it to transmit data. Do NOT use XON/XOFF or "hardware" flow control.

Cris,

I did. From the Silicon Labs website, installed, then plugged it in the USB. Tera Term recognizes it but no amount of adjusting the settings causes data to flow. I also tried it on another pc running a different version of windows with no effect.

 

[waltr]

Dumb question (but I've done this):
Are the TX & RX lines from the dongle connected to the correct pins on the Eggtimer?

 

[cerving]

Did you get the addendum about the differences between the USB cable and the dongle? Most issues with it are in here...

 

[Zbench]

I've made some progress, but not all. I determined that one of the leads on the cable I was using was faulty. I tried different leads and I can access GPS data using visual GPS by connecting to the Ground and RX pins. Its amazing how fast the Quasar picks up 5 satellites even inside.

Buoyed by this, I tried the ground and TX pins for password recovery, I've tried in on Quantums, Ions, and the Quasar, I just cant get the data to flow. I've tried in putty, Tera Term and Kitty. Set to 115200 baud. Tried different cables too and different pins on those cables. The only thing I can conclude is there is something wrong with the TX circuit.

Thoughts?

 

[Tractionengines]

Have you tried an old cable on a Windows 10, or older computer.

 

[Zbench]

I have, installed the driver on a windows 7 machine and again it sees the emulator but does not stream data on the TX pin

 

[cerving]

I've made some progress, but not all. I determined that one of the leads on the cable I was using was faulty. I tried different leads and I can access GPS data using visual GPS by connecting to the Ground and RX pins. Its amazing how fast the Quasar picks up 5 satellites even inside.

Buoyed by this, I tried the ground and TX pins for password recovery, I've tried in on Quantums, Ions, and the Quasar, I just cant get the data to flow. I've tried in putty, Tera Term and Kitty. Set to 115200 baud. Tried different cables too and different pins on those cables. The only thing I can conclude is there is something wrong with the TX circuit.

Thoughts?

The Quasar does everything at 9600 baud, including the diagnostics. If you're trying to do it at 115,200 baud, it's not gonna work...

 

[Zbench]

So after much time and effort, I finally did get this to work. I didn't change the port settings from whatever window assigned. The problem is that apparently, the RX port on the dongle, needs to be connected to the TX port on the Eggtimer Device. Below is screenshot of the result. I'm not sure how other than through trial and error anyone would know this. Cris, is this something you have seen before? I'm using Tera Term, settings below. Thanks to member sriegel for putting me on this trail. Also works similarly for the Quasar, except the baud setting needs changed to 9600 as Cris noted above. I hope this saves some people some time. Seems like there is a big difference between the pin connections in the older serial cable and this new dongle.

 

[Zbench]

Throwing ALL caution to the wind, I decided to update that same Quantum to the newest version of the firmware. To do so, I swapped the pin feeds as above. RX on the Device was connected to TX on the Dongle, and in a similar fashion, TX on the Device, was connected to RX on the Dongle. The upload worked perfectly and without an issue.

 

[waltr]

From the doc Cris posted above, the new Win11 dongle's wire colors are not consistent so you must try combinations to find which wires are TX & RX....

Then the nomenclature of RX & TX is not always consistent amount different devices. However, the most consistent is the data flow direction on a device. Therefore TX on Dongle is a data output on that wire, Conversely, RX on the Eggtimer is an Input. So, an output must go to an input or TX -> RX.

Once I figure out which wires are RX & TX I put a label on the wires so next time I can get the correct connects. Same with the Ground and power wires.

Good you finally figured it out and everything is now working.

 

[Zbench]

Waltr, I get the caution about the cable, and am astute enough to realize that regardless of cable color you need to make sure that you connect the proper pins on dongle and device. However, that doesn't account for a big disconnect in what has been offered as the correct connection sequence. I wonder if the board could be screened improperly? Where as before it was TX->TX, RX->RX, GND->GND it is now TX->RX, RX->TX, GND->GND

 

[waltr]

This is the biggest issue in pin nomenclature on all kinds of devices with serial interfaces.
Been fighting this kind of naming to get the correct connections for 45 years.

The Name TX or RX all depends on the 'point of view' the developer is thinking of.

When is is TX -> TX then the point of view is as a System data flow from Host device to slave device.
When it is TX -> RX then point of view is the individual devices data flow.

So when two 'independent' device are connected data flow out of TX and into RX, thus TX -> RX.

 

[Zbench]

Waltr, this is all good to know. For those not steeped in the history and lore of serial device naming conventions, hopefully this will save others time, or Cris might consider indicating the various possibilities in his online support materials so folks don't waste hours of time experimenting.

 

[Tractionengines]

At least almost always swapping the TX RX lines doesn't damage anything... and YES the nomenclature of the data pins is very inconsistent for MANY MANY YEARS. I've seen the same model of device change to a new Rev and have the naming switched.

As @waltr says its all perspective of the designer. One does it one way, next rev is someone else who's always done it the other.

( The issue can also come up in DC power loops "+" & "-" can be labeled as to what "goes there" or what "it is" ... a snubber circuit goes opposite the rectifier circut, and if parts only have +/- I dig out the diode test on the multi-meter to make sure it gets connected correctly. )

 

[cerving]

There IS a convention for the TX/RX confusion, it has to do with whether the device is a "terminal" device or a "communication" device. For terminal-to-terminal (i.e. a null-modem cable, such as you would use to connect two computers together) you swap the pairs... TX-->RX and RX-->TX. For connecting to a modem or communications device, they are the same... TX-->TX and RX-->RX. You pretty much gotta be an old fogey to know about the DTE/DCE stuff... especially as it relates to hardware handshaking.

 

[g.pitts]

There IS a convention for the TX/RX confusion, it has to do with whether the device is a "terminal" device or a "communication" device. For terminal-to-terminal (i.e. a null-modem cable, such as you would use to connect two computers together) you swap the pairs... TX-->RX and RX-->TX. For connecting to a modem or communications device, they are the same... TX-->TX and RX-->RX. You pretty much gotta be an old fogey to know about the DTE/DCE stuff... especially as it relates to hardware handshaking.

Don't forget CTS/RTS.

 

[cerving]

CTS/RTS and DTR/DSR were almost never implemented according to the original RS232 spec, especially in printers. They would use DTR where CTS was actually appropriate... connecting serial printers was always an adventure back in the day. That's why they came up with XON/XOFF... which had its own set of issues.

 

[Handeman]

CTS/RTS and DTR/DSR were almost never implemented according to the original RS232 spec, especially in printers. They would use DTR where CTS was actually appropriate... connecting serial printers was always an adventure back in the day. That's why they came up with XON/XOFF... which had its own set of issues.

I remember that well. Connecting IBM main frame equipment to a comm format interface PC to a Data General 7800 mini computer because IBM wouldn't talk to Data General. Even when you get the connection right, the timing was still a nightmare and based on serial copper com cable lengths. Especially when the PC application was written in assembler for speed and bypassed all the DOS OS and operated all the H/W directly. To make it worse, there was no copy of the latest version of the assembler code available so there was no way to adjust timing. Good thing they paid me well.