I’m trying to use Sparkfun’s WiFly GSX as a compact telemetric data acquisition device. I chose the wifly partly because of its 14 bit A/D converter (i.e. better than Xbee which has only 10 bits and most arduio-boards) but I must admit that my experience with electronics of this type is very limited.
The idea is to use an adhoc connection between a PC and the wifly (mainly to keep things as simple as possible), and use the A/D inputs of the Wifly to sample a number (up to 8 ) of pressure sensors. I would like sample at as high rate as possible (~1 kHz).
Reading the reference guide I have been able to recognize three different ways to sample the A/D-inputs:
UDP Broadcast
HTTP Broadcast
“show q” command in command mode
AFAICS the first two alternatives disqualify because they have a maximum broadcast rate of ~0.5 Hz. So even though I would have preferred some kind of broadcasting soultion (instead of having to send a command each time I want a sample to be taken) I chose alternative number three.
Status so far:
Adhoc connection seems to work fineusing the default settings.
Connection with telnet terminal works fine.
Manual sampling in command mode using “show q” works fine for low sample rates (a few Hz)
However, when I try to increase sample rate I get into trouble. I can get really fast sampling for a while, but then it start to stall with uneven intervals. I don’t really have any knowledge in TCP/IP communication but I think that it could be that the responce of the wifly is too slow.
I would be very grateful if someone could suggest a better way of accessing the A/D pins of the wifly.
Or if someone could give me a hint on how to maximize the data rate when using “show q” in command mode.
1 kHz is indeed a bit more than we need at the moment for measuring pressures. But if we get this setup working we might consider connecting other sensors to measure e.g. vibration, strain et.c.
Its ok if we don’t reach 1 kH, but the main problem now is that the sample rate isn’t constant (i.e. sampling stalls for a while before continuing).
I’m currently developing a system very much like yours. I already tried sending the ‘show q’ requests, but couldn’t get the data rate up. My theory is that command is sent via TCP/IP protocol, so there is a large header attached to the ‘show q’ command and another large header attached to the result string. So, the channel is mostly occupied by header information, preventing large data rates.
I eventually broke down and purchased an arduino pro mini to do my A/D, but am still having trouble getting my data rate up. Even when sending HEX using UDP with max packet size filled with data, I’m only around 1.6 kHz sampling frequency. I haven’t isolated if the problem is with the Wifly module itself, my router, or receiving computer.
I was able to parse the data from either UDP broadcast or TCP client mode. I was also able to automatically get the sensor data using “show q 3” but the readings are nothing near correct.
For example I used the Pin 19 on RN-XV ( – SEN3 – which has a voltage divider of 100k/570k) and multiplied the value I get with 5.7 to get the correct values.
I also tried the method at http://bjornsenfamily.com/blog/?p=69 (removing the 100K and short circuiting the 470K so that there wouldn’t be a voltage division. (since my highest output was much less than 400mV this looked alright for me too))
But I don’t get the same value I see on the multimeter: