Fake and Bridged Mode
— Kenny Luong 2020/04/19 23:34
Page is currently in progress, change is not yet in master.
Summary
These two features will allow developers to test changes to the gateway without needing a full network setup with devices and XBees.
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. |
How it works
Normal Setup
This is what the normal pipeline looks like:
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
Bridged Mode
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:
Fake Mode
Fake mode takes bridged mode one step further and takes all hardware away completely:
Why?
It's important to have a testing process that easy and can be done without the production environment, otherwise you'll always be trying to test in production!
Further Improvements
- 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
- Deployment needs to be better
- systemd
- Command line args could use some cleanup
Further Reading
The frame descriptions listed on the digi website are actually really helpful.