Differences
This shows you the differences between two versions of the page.
weatherbox:gateway:fake_and_bridged_mode [2020/04/20 16:19] kluong [Further Improvements] |
weatherbox:gateway:fake_and_bridged_mode [2021/09/19 21:59] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Fake and Bridged Mode ====== | ||
- | --- //[[[email protected]|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! | ||
- | |||
- | <code bash> | ||
- | (env) kluong@kserver:~/control_tower/gateway/src$ python gateway_server.py fake | ||
- | Setup | ||
- | Setup XBee Device | ||
- | Starting main Gateway Loop | ||
- | </code> | ||
- | |||
- | |||
- | <code bash> | ||
- | (env) kluong@kserver:~/control_tower/gateway/src$ python gateway_server.py bridged /dev/ttyACM0 | ||
- | Setup | ||
- | Setup XBee Device | ||
- | Starting main Gateway Loop | ||
- | </code> | ||
- | |||
- | **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: | ||
- | |||
- | {{drawio>weatherbox:gateway:normal_mode}} | ||
- | |||
- | The microcontroller on the weatherbox side sends a [[https://www.digi.com/resources/documentation/Digidocs/90002002/Reference/r_frame_0x10.htm?tocpath=Frame%20descriptions%7C_____3 | transmit request]] to the remote xbee: | ||
- | |||
- | The coordinator xbee (attached too the gateway), then sends a [[https://www.digi.com/resources/documentation/Digidocs/90002002/Reference/r_frame_0x10.htm?tocpath=Frame%20descriptions%7C_____3 | 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: | ||
- | |||
- | {{drawio>weatherbox:gateway:bridged_mode}} | ||
- | |||
- | |||
- | |||
- | ===== Fake Mode ===== | ||
- | |||
- | Fake mode takes bridged mode one step further and takes all hardware away completely: | ||
- | |||
- | {{drawio>weatherbox:gateway:fake_mode}} | ||
- | |||
- | |||
- | ====== 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 | ||
- | * staging environment? | ||
- | * Command line args could use some cleanup | ||
- | |||
- | |||
- | |||
- | ====== Further Reading ====== | ||
- | |||
- | The [[ https://www.digi.com/resources/documentation/Digidocs/90002002/Default.htm#Containers/cont_frame_descriptions.htm%3FTocPath%3DFrame%2520descriptions%7C_____0 | frame descriptions ]] listed on the digi website are actually really helpful. |