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.