Summary

After talking to the current firmware team (who is responsible for the gateway at the moment), I've finally managed to get around to some improvements for testing - two different modes that don't require a full weatherbox to be operational for gateway development!

(env) kluong@kserver:~/control_tower/gateway/src$ python gateway_server.py fake
Setup
Setup XBee Device
Starting main Gateway Loop

(env) kluong@kserver:~/control_tower/gateway/src$ python gateway_server.py bridged /dev/ttyACM0
Setup
Setup XBee Device
Starting main Gateway Loop

Fake mode will work on scelserver without any additional modifications, so feel free to give it a try when you get a chance.

These two modes allow for testing the gateway without having a working weatherbox. When used, these are how the modes work:

Mode	Description
Fake Mode	This mode does not require any physical devices at all; it simulates a weatherbox network by sending packets from multiple types of weatherboxes in an infinite loop.
Bridged Mode	This mode allows you to hook up a physical device that emits TX frames onto uart lines. This could mean a full weatherbox, or just a microcontroller running a stubbed version of the normal firmware.

This is what the normal pipeline looks like:

weatherbox:gateway:normal_mode.png

The microcontroller on the weatherbox side sends a transmit request to the remote xbee:

The coordinator xbee (attached too the gateway), then sends a receive packet frame through uart:

So, if this is how things normally work, we'd need some hardware to test the gateway to see that it's decoding packets correctly. We'd need:

A weatherbox
2 XBees
A usb serial adapter to connect to the XBee on the hardware side.

This is problematic for a couple of reasons:

Setup is complicated and cumbersome
Setup is expensive

I realized that if I could have some script running that could translate transmit request frames to receive frames on the other side we could connect a weatherbox (or microcontroller) directly to a gateway to test it:

weatherbox:gateway:bridged_mode.png

Fake mode takes bridged mode one step further and takes all hardware away completely:

weatherbox:gateway:fake_mode.png

Automated testing: this is important, because as the software gets bigger it gets harder and harder to test all of the cases manually by running the whole program.
- Unit testing
- End-to-end testing
Packaging story needs to be better; hard to run application with virtualenv

The frame descriptions listed on the digi website are actually really helpful.