Two days of hard work has not resulted in making this application work correctly. I’m an embedded engineer with years of experience. I have a good serial port monitor, as well as your own serial transmitter for testing. I’m using a known serial input (produces GPS coordinates reliably for other applications). This is being run on XP. The two modules were purchased 3 weeks ago, pre-wired.
Lights flash as they should. The configuration utility says the latest app has loaded correctly with correct port baud rate, etc. The input is correctly wired (3.3v levels)…
The two monitors show nonsense bytes. Connecting the same input to my Belken serial-USB interface works as before, so the input is fine.
I suspect that the Windows XP driver is not up to it (I loaded this as the manual indicates).
Any suggestions?? It seems to be a great product with lots of thought, good manual, etc. I just can’t make it work.
Further to my previous posting, I’ve looped-back the Tx-Rx and what I send I get back OK. The Wixel seems to be working OK, but what it gets from my ‘reliable’ serial input (correct baud rate, stop bits, etc.) is not correct. Is it possible that the Wixel is inverting bits at the input?? Maybe transposing bytes in octal words??
I’m sorry you are having trouble with the Wixel. It should work fine in Windows XP SP3.
What Wixel App have you loaded onto your Wixel(s) and what settings did you choose? How is everything connected? What settings did you select when you started your terminal program (baud rate, stop bits, parity, etc.)?
You seem to be Pololu’s technical guru. Well done. As I said, having done lots of commercial embedded stuff over the years, I really appreciate what you’re doing.
The app I loaded was wireless_serial_v1.2.wxl (I see there’s now a v1.3). The parameters were the defaults (9600,1,N), which match my other serial hardware/software. The configuration check/app integrity with the config utility all check. There is no flow control on the GPS serial source (none is set or configured on the Wixel), just Rx / Gnd. This works fine for the Belken unit as well as the old serial port on an ancient PC.
Everything seems right, except the data is wrong. It reads read data when there’s data there. The green LED flashes as it should. The Wixel responds to commands correctly. If I do a loop-back it’s all just fine with data injection, so the Wixel input circuit has not been compromised. Very puzzling. It’s like it’s reading garbage out of a buffer (I’ve tried disabling the buffer in the Windows dll, to no effect).
The behavior you are seeing is, of course, consistent with a mismatch between the baud rate of the Wixel’s UART and the baud rate of the data from your GPS. If you are using the Wireless Serial app then you must use the Wixel Configuration Utility to set the correct baud rate; the Wixel will not obey the baud rate that you choose when you open the terminal program. That’s why I asked “what settings did you choose?”
Your answer to that question makes me think that we have miscommunicated, because “9600, 1, N” describes settings for a COM port and does not describe settings for a Wixel running the Wireless Serial app. The settings for the Wixel are selected in the Wixel Configuration Utility. There is a baud rate parameter, but there are currently no parameters for stop bits or parity. The parameters are listed on this page: pololu.com/docs/0J46/9.b
What baud rate did you select in the Wixel Configuration Utility and what baud rate does your GPS use?
I’m aware of this. The baud rate (9600) is the default already set when the application was loaded. It happens to be the same as set in the Port and on my data-generating application. I don’t think this is the issue. Everything is actually working at 9600. I’ve used the configuration utility to ensure that this is so.
Something odd going on with the Rx input. If I load the wireless_serial_v1.3.wxl the red led is permanently on in the UART->USB app. If I send the UART Rx input a series of 0x01 bytes I receive on the Wixel I usually receive a series of 0xFD bytes as though there is a bit slip and bit inversion. Conversely sending 0xFE bytes I receive 0x80 bytes (though not usually the same number of bytes as sent). Everything is working on 9600 / 1 stop bit.
Perhaps the Rx input is buggered. I’ve used the TTL resistive divider.
One last post. My test system is quite simple. A Serial-USB adaptor (Unitek or Belken) is connected to the Wixel through a couple of DE9 connectors/cable. Only Tx,Rx and GND are connected. The Wixel is powered with 6V and connected to another USB port through its cable. The Wixel has a 1K/2K divider at its Rx input (as shown in the manual for TTL inputs).
I send bytes to the Wixel through a serial test program (one of the ones you recommend). I use the Pololu serial test program on the receive end. I send bytes and look to see if I get the same ones on the Wixel. I don’t, as indicated in the previous posting. I should if this is going to work like the other commerical UART(serial) USB interfaces (as the manual says it should for the loaded app). The radio part is fine and not a part of the problem.
Cheers and thanks for any help in setting up the input to achieve the above.
As a casually interested reader of this forum, I would like to comment that your description of the setup is very unclear, making it nearly impossible for David to help you figure out what is wrong. Why not tell us exactly what GPS module you are using, and verify the exact format of its serial output (TTL (0-5V) inverted or not). A schematic diagram showing the details of the connections between your GPS module and the wixel would help immensely.
I agree with David that it sounds like you are trying to connect an RS232 interface (else why the DE9 connectors?) using signal levels nominally between -12 and +12 volts, to a 3.3V (not even TTL!) interface.
As an aside, despite my >40 years of experience with electronics, serial interfaces continue to be one of my most frequent sources of aggravation.
I no longer care what the GPS unit does. (A Garmin I’ve used for years, no detailed manufacturer information at all on it’s output spec, but it does plug directly into any number of standard serial-USB adaptors with no problems). Forget about the GPS, that’s just ultimately what I intend to do with the Wixel (if I can get past first base).
The issue is, instead, whether the Wixel in its UART to USB application behaves like any other similar device. In this case I am connecting it to a commerical (Belken) serial-USB adaptor. Sending bytes out through a PC Port (which works – can check with another adaptor and serial monitor) to the Wixel and looking at what comes back from the Wixel. Simple as! I’ve used a number of these readily available serial-USB devices, and that’s all I’m trying to get the Wixel to do (the applications says it does). Once that can be accomplished, the rest will follow.
What do you have to do the the Wixel input to couple it to the input/output of one of these devices? TTL was simply the safest input protection, I thought. There was nothing else in the application note to suggest that elaborate level shifting/buffering/logical inversion, etc., was required.
I, also, have had years of frustration with serial/RS232 interfaces and software. I didn’t expect this to turn into a research project, just load the application and get on with the rest of my life. I also don’t want to write a lot of software (I do that for a living, as it is). It’s tantilizing, but perhaps not quite there yet. Likely to be a simple hardware interface gotcha.
All the older Garmins (I have the Etrex) use the RS232 standard, which is +/- 12 Volt inverted logic. To my knowledge, the newer ones continue to use that interface but have added a USB interface (I also have the 60CSX).
To connect a Garmin to a wixel via the Garmin’s RS232 serial port, you will need an RS232 to TTL level converter AND drop the voltage levels from the level converter’s output TX line (0-5 V) down to 0-3.3 V, using a resistive divider. If you use the Pololu RS232-TTL serial adapter, which can be powered by 3 V, you don’t need the resistive divider. That unit has worked well for me in exactly this application, see pololu.com/catalog/product/126
Apologies if my response was a bit testy. Just frustration in what was turning into a research project when it seemed to be nearly an ‘out-of-box’ solution. Pololu seem to have a number of interesting products, and I’m a new-comer to their line.
As I indicated in the earlier email, I am impressed with the company and their products.
