kd8bxp
commented
7 years ago I can check off a couple of the things on this list. I would love to hear from the creator thou about some of these changes. On the ESP32 branch that I've been working on, I have the BEACON sketch sending JSON strings, and the PAGER Sketch decoding the strings. I am able to phase that string and display it nicely. Using JSON it also easy to change the data that is being sent. The String looks something like this: {"TO":"BEACON","FROM":"KD8BXP-10","MESSAGE":"this is a message","RT":""} If each Gateway/Pager phases the data, adding a RT would be simple - It might even be good to have the RT as an array, within the JSON string We could also add to the protocol, such as a "GATEWAY" object which would tell the gateway to send the package to the internet - it could also remove the "GATEWAY" flag when it does this so the next gateway doesn't gate it. Maybe a "HOP" count, so it doesn't get RT alot (which is something I can see happening if/when the network gets busy)
I would also like to propose a change from using BEACON to maybe SENS for SENSOR data being passed, and reserve BEACON to announce that there is a LoRaHam network in the area. I would also like to propose adding the following: CQ - For general calling and see who is out there - pagers would get the CQ NET - used to start and respond to a NET BLT (0-9) Bulletins used to make announcements to everyone SPCL - for special event stations (I'm not sure if this would be used, but you never know) WX - for weather stations - LoRa and Microcontrollers really lean themselfs to something like this. (I would also say these stations should be keep local, and not gated.) SENS - Other type of sensor reading/RC control/etc - and should be keep local and not gated CMD - a specific (different) protocol to command and control a remote BEACON or DIGI - should only be used local, not gated and only by the system operator (I haven't thought much more about this so a lot of thought would have to be put into something like this)
I would also suggest adding a general location to the protocol, that would help to keep packages that need to stay local - local. It wouldn't need to be precise maybe just the grid square like for me EM79 would work, even thou I do travel and sometime leave me "home" grid.
jmi2k
Couple of thoughts I had while converting the pager.ino for use with a ESP32 board 1) Tokenize (sp) the sending string - making it easier to manipulate on the rx side. IE:
BEACON KD8BXP-10 VCC=3.742 Count=123 200mAh ESP32would become something like thisBEACON;KD8BXP-10;VCC=3.742 Count=123 200mAh ESP32And for RT it would become something like this:
BEACON;KD8BXP-10;VCC=3.742 Count=123 200mAh ESP32;RT KK4VCZ rssi=-46The next RT would just add to the end without another ";" IE:BEACON;KD8BXP-10;VCC=3.742 Count=123 200mAh ESP32;RT KK4VCZ-16 rssi=-46 RT AB3XL-10 rssi=-80This could be easy split, for display on a small OLED or other small screen.
To: BEACON From: KD8BXP-10 MSG: VCC=3.742 Count=123 200mAh ESP32and on another screenRT KK4VCZ-16 rssi=-46 RT AB3XL-10 rssi=-80if there are RTs2) My other thought would be to add some type of RT count, or the ability to know if "you" have already RT the packet. That being said, I have only looked at the code for BEACON and PAGER at this point. And if a filter is build into the gateway code then disregard this idea :-) (software could do this pretty easy)
3) You might considering adding something to the protocol that would tell a gateway to gate the message to the internet. And a way to track that it was gated, so it doesn't get gated a bunch of times. I'm thinking maybe a semi-private MQTT server somewhere, the gateways could subscribe and publish to a "LoRaHam" topic for passing messages across the internet. I need to think about this idea a little more, and see how that fits into the plan. Using MQTT clients could be written that just use the internet to pass traffic.
Some other ideas go into hardware design for the "pager" -
The board I have is a WIFI_LoRa_32 board, I found cheap on Aliexpress. It's is a ESP32, a 433Mhz SX1278 LoRa board, has a OLED (.96 I think), battery connector, and lots of GPIO. It's not without it's issues - Like radiohead library doesn't compile with it (hench, converting BEACON and PAGER to a different library), The Adafruit_SSD1306 doesn't work with it. (Someone converted that library for the ESP8266 and called it ESP_SSD1306 it's a drop in replacement for the Adafruit library) Unfortunately I couldn't get ESP_SSD1306 to work. And had to use a different SSD1306 library (link is in the sketch) But it was not a direct drop in replacement. Another issue with the board is some of the GPIO pins are covered by the OLED screen (IE: it would be hard to solder pins without damage to the screen - and something I need to look at closer)
Some of my ideas to add to the hardware/software:
1) Add a buzzer with a sound for "your callsign" and a different sound for the BEACON messages - this should be pretty easy to do. A Vibration motor would work just as well. 2) Add some DIP or other Switches - to turn on and off different features with out a need to reload a new sketch each time. This too should be pretty easy to do with a little thought as to what features you want to control. 3) A button or two to review the last message received - the button could also be used to move to the next screen when a message is too large to display on one screen. A little harder to do with out splitting the string (IE: my idea above) Specific to the ESP32 hardware: 1) WIFI website/api to compose and send a short message from the pager. I think this will be fairly easy to do (?) Not sure how the ESP32 handles forms, so a API style maybe better (?) Lastly 2) Using the ESP32 bluetooth and a bluetooth keyboard to compose and send a short message from the pager. I'm not even sure this can be done, it's just a thought.