I don’t see PA15 referenced anywhere in the source or in this forum, apart from your post. Have you thoughts about how to turn the GPS on and off? Probably on a schedule, set as part of the configuration that includes commissioning. It would probably be better if there was a power saving mode, because in my experience, a GPS that is doing a warm start (because it’s kept the latest ephemeris) can get a sync in about one second. If you turn its power off, it has to re-acquire the ephemeris, which can take 90 seconds.
It has a power save mode.
It’s PA_15, Russell. And it is referenced and used by GpsStart and GpsStop, but GpsStop is only called in the ComplianceTest code. So there’s no inherent GPS power saving by the tracker.
Hmmm… the CPU has EEPROM. Better place to store the commissioning data than in the source code.
After doing that, the next step is to include the source code for all regions, so that the region becomes a run-time setting rather than a compilation option.
With those two changes to the code, the only people who would need to recompile it are people who want to change the source. It’s most important to put the commissioning into EEPROM, because then you can create a set of binaries, one for each region. Then, the mundanes can just reflash with their region, which is a LOT easier.
Urgh. Attempting to read from fd0 (aka stdin) using getline or read fails. I get a -1 error code from read’ing. Anybody ever used this system to read characters from the USB port?
You can program power save mode using their proprietary protocol: https://www.u-blox.com/sites/default/files/products/documents/u-blox7-V14_ReceiverDescrProtSpec_(GPS.G7-SW-12001)_Public.pdf
OK. So you added a hdop byte in the data format and one has to add the decoder manualy to the things network application. I will test this.
Hey I have been following your comments. I am having a problem connecting my device to ttn. I have changed the EUIs and application keys. I have also changed the frequency in platformio.ini to US915 as you suggested. Unfortunately all I get is this:
OTAA:
Dev_EUI: xxx…
AppEui: xxx…
AppKey: xxx…
OTAA Join Start…
Are you using my version of the code? Because you also need to change the LORAWAN_DEFAULT_DATARATE to DR_4. My code does that when you change the region to US915. Without that, no go. Also, my code tells you the return value from SendFrame, so that if you’re not getting 0, you can track down the error you’re getting.
Yes. After adding the decoder (and note that I changed the data format to match @jpmeijers’s as he used in his arduino code, so the decoder.js and mapper.c must match), you must also add ttnmapper as an integration. Otherwise it won’t know to look at your GPS data.
It reduced around 20mA.
You can just use GpsStop() to do this. You can check that it use GpsMcuStop() as in gps-board.c
void GpsMcuStop( void )
{
GpioWrite( &GpsPowerEn, 0 ); // power down the GPS
}
1 Like
I’m using Ebiroll version code, you can just search GPS_POWER_ON_PIN and you will find it defined for PA_15. Yes the GPS need 90 seconds to acquire. My application only need the GPS coordinate during startup, so this can be managed.
1 Like
yes I already read this. Any information for sample code sent to activate PSM via its UART?
I downloaded your gps-node-examples-master folder. Here is what I did all in atom:
Opened gps-node-examples-master, modified Commissioning.h, added rak811.json to ststm32 boards, modified platform.ini to US915. Then ran gps-node-examples-master\RAK811-Tracker> pio run. It returned :
Calculating size .pioenvs\rak811\firmware.elf
text data bss dec hex filename
52612 1564 5956 60132 eae4 .pioenvs\rak811\firmware.elf
===== [SUCCESS] Took 4.99 seconds=====
In UART terminal I get:
RAK811 BreakBoard soft version: 1.0.2
Selected LoraWAN 1.0.2 Region: US915
OTAA:
Dev_EUI: xxxx
AppEui: xxxx
AppKey: xxxx
OTAA Join Start…
Where and how do I change to LORAWAN_DEFAULT_DATARATE to DR_4?
I am pretty new at this and had to read a looooot just to get to where I am now. Could you give me some more detailed help please. I truly appreciate it!!!
My goal is to use the Rak811 tracking to output on the ttn mapper. I have a gateway already setup to US915.- Thank you
Indeed they do, most of the UBLOXs can be sent a command to go into low power mode and that can be used as a basis for a warm start setup. It wakes up on activity on the GPSs RX pin.
Current consumption varies depending on the model, but generally 100uA to 50uA.
I think now it is already done. You can see it in mapper.c in lines ~90 and ~95 that for US915 it is defined DR_4.
If your version is not updated enough, you have to delete (again in mapper.c) line 40 an add two defines in the lines I mentioned before like that
#define LORAWAN_DEFAULT_DATARATE DR_5
Before line 93 and
#define LORAWAN_DEFAULT_DATARATE DR_4
before line 97
Oh OK. But I still got,
{
“alt”: -18311,
“hdop”: 0,
“lat”: -88.92324322004576,
“lon”: -155.78059528950425
}
From
018809113902B879000AF0
Should have been something more like,
“latitude”: 59.423046,
“longitude”: 17.829844,
decoded.lat = ((bytes[0]<<16)>>>0) + ((bytes[1]<<8)>>>0) + bytes[2];
decoded.lat = (decoded.lat / 16777215.0 * 180) - 90;
decoded.lon = ((bytes[3]<<16)>>>0) + ((bytes[4]<<8)>>>0) + bytes[5];
decoded.lon = (decoded.lon / 16777215.0 * 360) - 180;
var altValue = ((bytes[6]<<8)>>>0) + bytes[7];
var sign = bytes[6] & (1 << 7);
if(sign) {
Hmmm…
I use some similar like this one: Best practices when sending GPS location data
this for the encoder:
int32_t lat = latitude * 10000;
int32_t lon = longitude * 10000;
int16_t alt = altitudeGps * 100;
int8_t hdev = hdopGps * 10;
if (ret == SUCCESS) {
AppData[0] = lat;
AppData[1] = lat >> 8;
AppData[2] = lat >> 16;
AppData[3] = lon;
AppData[4] = lon >> 8;
AppData[5] = lon >> 16;
AppData[6] = alt;
AppData[7] = alt >> 8;
AppData[8] = hdev;
AppDataSize = 9;
and this for the decoder:
function Decoder(b, port) {
var decoded = {};
switch (port) {
case 2:
var lat = (b[0] | b[1]<<8 | b[2]<<16 | (b[2] & 0x80 ? 0xFF<<24 : 0)) / 10000.0;
var lon = (b[3] | b[4]<<8 | b[5]<<16 | (b[5] & 0x80 ? 0xFF<<24 : 0)) / 10000.0;
var alt = (b[6] | b[7]<<8 | (b[7] & 0x80 ? 0xFFFF<<16 : 0)) / 100.0;
var hdop = b[8] / 10.0;
decoded = {
"location": {
"latitude": lat,
"longitude": lon,
"altitude": alt,
"hdop": hdop
},
};
break;
case 3:
var bat = (b[0] | b[1]<<8 | (b[1] & 0x80 ? 0xFFFF<<16 : 0)) * 10.0;
decoded ={
"battery":{
"bat":bat
}
};
break;
case 4:
var aX = (b[0] | b[1]<<8 | (b[1] & 0x80 ? 0xFFFF<<16 : 0)) / 10.0;
var aY = (b[2] | b[3]<<8 | (b[3] & 0x80 ? 0xFFFF<<16 : 0)) / 10.0;
var aZ = (b[4] | b[5]<<8 | (b[5] & 0x80 ? 0xFFFF<<16 : 0)) / 10.0;
decoded ={
"acceleration":{
"aX":aX,
"aY":aY,
"aZ":aZ,
}
};
break;
}
return decoded;
}
Tested in Salamanca (where I have negative longitude) and Budapest (all positive) and good results
That’s going to run out of bits to hold any altitude greater than 327.67 meters. No need to multiply the altitude by 100.
While there’s nothing (else) wrong with your data format, I think it’s preferable to stick to the precedent set by @jpmeijers’es Arduino data format.
My code already sets DR_4 when in US915 and DR_5 when in EU868, so that’s not the problem. I don’t know why you’re having trouble with joining. You’re not doing anything wrong that I can see, and you haven’t made any mistakes I made. Double-check your credentials – if they’re wrong, a join will never work.