Support GPS enabled boards?

[samuk]

I was wondering whether it was a good idea to append the node id to the self-generated nicknames created by the user? If I have deployed a bunch of nodes I may know the node ID and the location of those nodes.

So if someone logs in and says "A truck full of water just got delivered here!" and then disappears, then I can use the implied location to go and get myself a bottle of water.

I'm thinking of the code that Is used in the access point name, I think it's based on Mac address?

You could strip out the 'disaster-radio' and just use the number? So nicks would be part user-generated and part machine-generated.

eg. Bob_0F733

Is this worth doing/ difficult?

[paidforby]

Yes, it is a great idea. However, I think this raises a larger question about how to handle identity on a disaster.radio network. Do users have a network-wide identity, into which they can log into at any node and gather their messages from all neighboring nodes? Or do users have a per-node identity? I don't have a preference, though I imagine per-node will be much simpler to implement and less bandwidth intensive.

Currently, the nickname entered into the demo chat app is very superficial as it does not correspond to anything other than a sender that is appended to the front of the chat messages sent during that websocket session. This nickname is not sent down and saved in any way by the firmware. Likewise, the node's address (mac address) is not sent up to web app. This means it would not be simple to append the mac to the nickname, but the option could and should be added.

Ultimately, I would like to see us add a config page to the node's web app where you could set a hostname for your node. That way "Bob_0F733" could become something like "Bob@123ShadyLane"

This is all good stuff to be thinking about as we work more on structuring the database to store and recall messages.

[samuk]

Just spotted this board for a few more $ that has a GPS in it
https://www.aliexpress.com/item/33046632533.html

It could be Nick-Lat/long?

[samuk]

The more I think about it the more useful I think the GPS function would be for almost all deployment scenarios.

[paidforby]

Certainly. I like the option of appending the node's coordinates to the chat nickname. GPS could also have some interesting use cases in the mapping application. I'll order a few of these and see about supporting them in addition to the LILY TTGO boards.

[samuk]

Looks like there is now provisional support for GPS

https://github.com/sudomesh/disaster-radio/blob/master/firmware/esp32/client/GPSClient.cpp
https://github.com/sudomesh/disaster-radio/blob/master/platformio.ini#L41

Does anyone have a Tbeam for testing? https://www.aliexpress.com/item/33046632533.html

[spattinson]

I have two TTGO TBeam. I am testing them out, they are sx1278 based ones so they are 433Mhz, I figured out how to change the LoRa frequency, bandwidth, spreading.
The GPS is defined in config.h #define GPS_SERIAL 9600, SERIAL_8N1, GPIO_NUM_12, GPIO_NUM_15 which is correct for TBeam the old TBeam (v07) the new TBeam (v10) pin 34 and 12, so I changed that. On bootup "initializing gps" is printed to serial console, but I dont see any location pings yet. The units are near a window where they normally get a signal ok. Not quite sure what the reason is, maybe I look at tinyGPS++ docs. Other examples I have seen usually initialise a serial link to the GPS.

I would be cool to request someone's location by their nick, or toggle broadcasting, either at the sending node of filtering in the client.

[samuk]

I think you're the first to try GPS enabled hardware.It might be worth looking at the Paxcounter code
https://github.com/cyberman54/ESP32-Paxcounter/search?q=gps&unscoped_q=gps

I think that's where the board definitions came from

[spattinson]

The sample code from the board vendor works and sends gps coordinates over lora along with snr and dbm. Its what i used initially to test range. Left one at home receiving and walked round town, got home and pasted coords into google maps to find furthest point.

[spattinson]

I think the reason GPS does not currently work on the TT-Go T-Beam is that the GPS needs to be powered on by the axp192 power management ic. The following extracted from https://github.com/Xinyuan-LilyGO/TTGO-T-Beam I think these are the relevant snippets needed. I am not experienced enough to add this is the correct places in Disaster Radio. I guess pax counter does something similar.

#define I2C_SDA             21
#define I2C_SCL             22
#define PMU_IRQ             35
#include "axp20x.h"
#include <Wire.h>

#ifndef AXP192_SLAVE_ADDRESS
#define AXP192_SLAVE_ADDRESS    0x34
#endif
AXP20X_Class axp;

Wire.begin(I2C_SDA, I2C_SCL);

  scanI2Cdevice();
 if (axp192_found) {
    if (!axp.begin(Wire, AXP192_SLAVE_ADDRESS)) {
      Serial.println("AXP192 Begin PASS");
    } else {
      Serial.println("AXP192 Begin FAIL");
    }

 
axp.setPowerOutPut(AXP192_LDO3, AXP202_ON);
axp.setLDO3Voltage(3300);   //GPS VDD      3v3
Serial.printf("LDO3: %s\n", axp.isLDO3Enable() ? "ENABLE" : "DISABLE");

[spattinson]

I flashed another project to my ttgo tbeam that switched on gps, then flashed disaster radio, so the gps was already switched on and the GPS works, got this in the console:

Welcome to DISASTER RADIO
WARNING: SD card not found, functionality may be limited
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
~ scott joined the channel
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62
<beacon> 51.48, -0.62

[gdt]

I see two problems with GPS. One is that it uses power, but for nodes that are planned to be stationary it could be used once and then turned off.

The larger issue is a privacy/security issue, which is really about location vs GPS. Someone might want to put up a node and not publish coordinates. So it should be up to the node administrator to choose to publish, done in such a way that it can't happen by accident. Node coordinates are of course useful for network maps, but I think network diagrams need to work without them also.

I would suggest using node coordinates only for network operations, and if it makes sense to have user-level messages have coordinates (e.g., "there is water here"), then the application-level messaging protocol should support that.

I have newly found this project, so I don't know if there are cultural norms, but it seems that the networking protocol has to be open in the cryptographic sense to admit joining nodes that are unknown, or at least that is a mode of operation that some will want. The messages going back and forth could be published (blog like), or they could be 1-1 or private groups, and encrypted. Without understanding, I am thinking of something like Briar operating over this.

[spattinson]

I agree. I think the devs just threw this in there to test if it works. I seem to be the only one on here with a ttgo t-beam so they couldn't test it themselves. Location should be requestable with a key word in chat by remote nodes that triggers a accept/deny question. The default on no response can be set at the beginning of a chat session to cover injured people that may need help and cant respond. Then gps can be in low power standby mode, which uses very little power, i think in the micro amp range.

[paidforby]

@spattinson Glad to hear you got this working! I actually have three T-BEAMs I've been meaning to test and you just gave me a very good reason to pull them out. Mine are the older V07s (at least they have T22_V07 printed on them). I'm going to see if I'm able to figure out how to properly turn on the GPS in the disaster radio code.

@gdt I agree, GPS or location publishing should always be off-by-default and opt-in-only. There are a number of folks interested in this feature, so we are trying to support it. You both have some good ideas for power-saving and use cases of GPS.