Jump to content
43oh

(MCU) Wireless networking question


Recommended Posts

We just received a small grant from NASA to build an educational activity/demo focused on rocketry.  We are going to build small payloads that contain a basic sensor package (pressure, accelerometer, gyro, temperature, etc) to sit in the nose cone of the rocket and transmit telemetry data back to a base station to display the data in real time.  These are going to be pneumatic (not real rocket engines), so the range will be restricted to hundreds of feet.

 

Right now we are trying to settle on the best wireless protocol to stream the data.  Communication only needs to be one way, but it needs to be simple and robust.  I would prefer something that supports multiple hosts, so I don't have to worry about activating/deactivating transmitters or returning the receiver.  The favorite so far is zigbee, but I'm not sure which flavor would be the best.  I'm also looking into wizfi modules so we can just use a wireless access point as the receiver and let the modules transmit a UDP data stream.

 

Can anyone who has experience with this stuff offer a comment?

Link to post
Share on other sites

Wifi can reach a pretty good range with the right antennas, which has me wondering if Bluetooth could be "modified" to do the same thing. For instance, when we used wireless internet in Nevada, the closest tower was 12-13 miles out. The tower its self used an omni directional antenna, and we used a Linksys wifi router ( modified ) with an Andrew 21DB antenna.

 

I do not know a lot about RF, but I still seems reasonable to me that bluetooth could be used similarly. Same frequencies, or close, and for a couple hundred feet with a good receiving antenna . . . yeah I do not know but may be worth at least looking into.

Link to post
Share on other sites

@@bluehash the data payload will be small.  This version will only be running around 4 sensors (gyro, accelerometer, temperature and pressure alt).  Right now I'm thinking about having each sensor transmit data in it's own frame to make the device more modular...adding sensors wouldn't require reworking the payload, just how many are sent.  So each payload will be a small text string, and I'm only planning on transmitting at somewhere between 10 and 100 Hz.  I think anything faster would be oversampling so bad that I would be filtering down to this rate anyway.  A mile of range would actually be kind of nice if it let me use this payload in real rockets as well....maybe expanded to include a GPS receiver

 

@@yyrkoon, my original idea was a bluetooth -> serial bridge with a tablet picking up the serial port wirelessly and processing the data on the fly.  I think bluetooth would have the range for this, but we finally decided that we want to be able to have multiple modules and quickly connect to them, which I think would be somewhat of a pain with bluetooth.

 

@@spirilis, is this what you are talking about?  

Link to post
Share on other sites

One thing @@jpnorair mentioned is that bluetooth does have RF characteristics that can intentionally self-limit its range although I'm not familiar enough with RF to understand how that works. Not sure if WiFi does the same but it seems like bluetooth wouldn't be an obvious choice due to that.

Sent from my Galaxy Note II with Tapatalk
 

Link to post
Share on other sites

One thing @@jpnorair mentioned is that bluetooth does have RF characteristics that can intentionally self-limit its range although I'm not familiar enough with RF to understand how that works. 

 

AFAIK range limiting is done by power only.

 

Here's a windy response.  Skip to the last two paragraphs if you want the quick answer.  :)

 

Assuming equal antennas, the range of a digital wireless comm is dependent on a few things:

1. the energy of a bit transmitted

2. the ability of the receiver to efficiently receive a bit

3. the propagation of the frequency (inversely proportional with frequency)

4. the level of noise in the environment (proportional with frequency)

 

If I transmit BLE at 1mW at 1Mbps (or the much-similar Nordic proprietary PHY), the energy-per bit is 1mW X 1us.  So, I can increase the energy per bit by increasing the power of the amp or by increasing the period of the bit (decreasing data rate).

 

SNR is fundamentally important, also.  One way to get better SNR is to filter the RX better.  Not surprisingly, this can be done by decreasing the data rate, which decreases the bandwidth, all-else-equal.  The term "bandwidth" is not equivalent to data rate, though.  It is just the amount of Hz that 99% of the signal energy can fit into.

 

The ability of the receiver to decode a bit is dependent on a bunch of calc and trig that I'm not going to explain, but all of that is dependent on the receiver topology itself.  Thing is, there are only three kinds of fundamental modulations: AM, FM, PM.  PM is phase modulation.  It cheap receivers it is much like FM in performance.  In practice, cheap receivers using FM and PM have the best performance.  In more sophisticated receivers, PM can be the best.  In hyper-sophisticated receivers (LTE, WiMax, 802.11n), what you get is a sort-of blend of FSK and PSK.  I've said too much already.

 

BLE uses GFSK.  G means Gaussian.  FSK means frequency-shift-keying, i.e. binary FM.  So, there is a filter on the transmission to "smooth" the bit, and this helps reduce the bandwidth at the price of making it slightly more difficult for the receiver.  In the end, it is usually a net-zero effect, although I think that most BLE implementations actually filter the TX a bit too much in order to meet spec, rather than use a clean analog chain (range is not a primary feature for BLE).  Filtering too much creates "ISI" or inter-symbol interference.

 

BLE also has more ISI.  This is because it uses "narrowband" FSK, actually super-narrowband FSK.  "Wideband" FSK includes some signal redundancy in order to make the receiver perform better in the presence of reflections and interference, at the cost of higher bandwidth.  But the plot thickens.  There is a point in the design of receivers where "narrowband" FSK gets so narrow where it is not possible to clearly identify 1 vs 0.  BLE goes quite a bit below this threshold, so some of the transmitter energy is not being used productively.  In fact, more than half of it is wasted in ISI.

 

WiFi 802.11b is quite pedestrian by modern standards.  It uses a variant of PSK.  g gets more complicated, n starts to get to the point where you need a big DSP to receive *as well as* cutting edge amps because it is sending more than one carrier.  WiFi is very sophisticated.  Bluetooth generally is not, but it is also much cheaper.  That said, an 802.11b implementation is dominated more by its obese IP stack than its PHY/MAC.

Link to post
Share on other sites

@@jpnorair, thanks.  That was really helpful.

 

I think we have decided that we want at least the option of extending range past what bluetooth or wireless will support, so I think we are going to order one of those boosterpacks @@spirilis suggested to start experimenting.  One question though... as I understand it, zigbee is just the standard which is implemented in a software stack.  Is that stack built into 'Air module', or is it implemented on the MSP430? 

 

@@cde, have you worked with that sensor board before?  I saw it had pads exposed for reprogramming, but do you know if it has pins broken out to interface it with a radio module...or would there be more reverse engineering involved?  The low power BT is actually a pretty nice feature on top of a longer range transmitter, as we are looking for a way to identify programmatically which rocket is loaded into the launcher and possibly initiate a 'launch sequence' to pull everything out of low power sleep.  

Link to post
Share on other sites

 

@@cde, have you worked with that sensor board before?  I saw it had pads exposed for reprogramming, but do you know if it has pins broken out to interface it with a radio module...or would there be more reverse engineering involved?  The low power BT is actually a pretty nice feature on top of a longer range transmitter, as we are looking for a way to identify programmatically which rocket is loaded into the launcher and possibly initiate a 'launch sequence' to pull everything out of low power sleep.  

Not personally, but the CC2541 SoC used on the chip is an 8051 compatible chip. (The CC2541 chip comes in a QFN-40 package and not only implements Bluetooth Low Energy, but has a internal  MCS 8051 micro-controller, general purpose timers, accurate RSSI support to allow range determination, two USARTs, 23 general purpose digital IO pins, 12-bit ADC with eight channels, I

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...