It seems when you define the RTC into the new gateway code, that you loose the USB port as a usb->serial. And the reason is because in the sleepsetup() call there is a USBDevice.detach() call. That probably doesn't do very good when trying to write output to the USB port for Serial.

operator should be able to send a message with a terminal like a PC or PocketCHIP to the loraham radio, and the loraham radio should transmit that message via RF.

This will allow the PocketCHIP to boot when connected

Use this issue to track details of refactoring the Gateway code for cleaner code and more efficient routing.

Some design concerns:

1. No new external dependencies should be added.
2. It's okay if Gateways must be M0 for a good reason.
3. Beacons should remain very simple and AVR compatible.
4. Code shouldn't use C++ features, as they are hard for beginners (and sometimes experts) to read.

@d235j and @sharph are assigned. Close this issue when the refactoring has been merged to the master branch without breakage.

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 ESP32 would become something like this
   BEACON;KD8BXP-10;VCC=3.742 Count=123 200mAh ESP32
   And for RT it would become something like this:
   BEACON;KD8BXP-10;VCC=3.742 Count=123 200mAh ESP32;RT KK4VCZ rssi=-46 The 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=-80
   This 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 ESP32 and on another screen
   RT KK4VCZ-16 rssi=-46 RT AB3XL-10 rssi=-80 if there are RTs

2. 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:
4. 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
5. 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.

The SX1276 datasheet warns that max duty cycle at +20dBm is 1% - suggest running max of +17dBm from the chip itself. I also note that the radiohead library seems to offer +23dBm which is not a documented power level from the SX1276 (or the RF95/RF98 re-badged parts).

Cheers,
Dana K6JQ

Hi

This is not really an issue, but I find the use of RadioHead a bit of overkill for such a simple protocol, and I'm also concerned that potentially RadioHead adds additional data to the start and end of the transmission.

I'm using the much more lightweight LoRa library from Sandeep Mistry

https://github.com/sandeepmistry/arduino-LoRa and it works fine.

Also RadioHead does not AFIK have an official GitHub repo, there is only a mirror that someone unofficially maintains.

Also, there are so many other, (cheaper LoRa) modules out there, that it would be good to support some other hardware than the Adafruit Feather.

I'm using some Ra-01 modules I bought from AliExpress for $4 and a $2 STM32F103C8 (Blue Pill board) as the MCU.

So total build cost is $6 including MCU.

When a solar charged device runs low on power, it dies. That much is unavoidable, but when the sun comes back and the LiPo recharges, the node stays dead, either because it is stuck in the bootloader or because it has glitched out.

Close this issue when we have either a software or a hardware patch that will have the devices cleanly reset when the sun returns. Better power management, such as entering low power modes for self protection, can be created as a separate issue.

Before we can make a public release, we need example tutorials to get folks started. These will go in the Wiki, and their purpose is to make it easy to build Gateways, Beacons, and Pagers. They must have good pictures and diagrams.

Examples in progress: (Check the box when complete.)

• Solar Powered Repeater
• Server Infrastructure

Close this issue when we have three or so example projects in the wiki.

I'm having a hard time finding a license for this project. I'm looking to play around with LoRa and have some transceivers on the way, but I don't feel conferrable pulling your code without knowing your intentions for it.

Any thoughts on LoRa using AES Encryption?
http://www.semtech.com/wireless-rf/internet-of-things/what-is-lora/
https://www.lora-alliance.org/what-is-lora
https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-LoRa-security-guide-1.2-2016-03-22.pdf
I've been looking for a way to turn it off, but it looks to me like even when no specified there is a key pair exchange.

Any thoughts on this and using it as a ham?

What range are you getting between your transmitters and receivers with omnidirectional antennas?

The new Gateway code goes to sleep immediately when no battery is wired to the feather board. A partial fix would be to never sleep when the serial port is connected.

Assigning to @sharph. Close this issue when the new gateway code works reliably on USB power without a battery.

In its current form, loraham uses the default modulation settings defined by the Radiohead driver. This configuration may suboptimal given the project's implicit goals of long range ad hoc networking. @travisgoodspeed and I have chatted about assessing the current settings and making a change if prudent.

The LoRa modulation has several proverbial knobs that can be turned to trade between throughput and range. The key parameters, their available values, and effects are:

• Spreading Factor ([6:12]): lower == throughput, higher == range
• Bandwidth (125kHz, 250kHz, 500kHz): lower == range, higher == throughput
• Code Rate (4/([1:4]+4)): lower == throughput, higher == range, optimal == 3 (see my note below)
• Low Data Rate mode: on == range, off == throughput

LoRaHAM's current settings are SF 8, BW 125kHz, CR 4/5, and Low Data Rate mode disabled. These are balanced settings that result in a medium range.

I'm happy to propose more suitable parameters. If this is of interest, let me lead by asking if there are any time on air or band usage restrictions for the 433 MHz HAM band you've targeted. This will help scope the rest of the discussion.

Resolved when compiling gateway for 32u4 (in addition to m0) is as easy as uncommenting or commenting a few #defines