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.
HDOP: Almost, but this gives you a range of -12.9 - 12.8. Rather go with unsigned ints to get a range of 0 - 25.6 because hdop will always be positive.
Altitude: Why do you need centimetre accuracy, while the altitude accuracy you get from the GPS is in the order of 10’s of metres. Better to stick to metre resolution to save space.
Lat: You multiply by 10000, so you end up with a value in the range -900’000 - 900’000. You then store it in a 32bit int, which has a range of -2’147’483’647 - 2’147’483’648. You are therefore wasting (4’294’967’296 - 900’000 - 900’000 / 4’294’967’296 = 99.958%!
Rather use the format as suggested by @RussNelson, which can be found on github. This format was designed to not waste a single bit, therefore maximising the resolution and minimising the LoRa time on air.
3 Likes
I was wondering about the reason of choice one or the other format, (@RussNelson suggested to use yours) , thank you for the explain, it saves me a couple of hours.
I will use your format as soon as I get some free time
My purpose was just to give OlofAst another way to test.
2 Likes
Hmmmm… I think I need a better antenna. I missed out on a bunch of places that I know have good reception. And/or increase the rate of transmission.
https://ttnmapper.org/special.php?node=crynwr-rak-1&alldates=on&gateways=on&lat=-76.36&lon=42.38
Hi
How would you go about connecting, a sensor to the trackerboard.
is there 2 gpio pins that i can use?
I have operational devices with GitHub - jcaridadhdez/RAK811-tracker: Example code for RAK811 nodes with GPS on board, transmitting their coordinates in the payload of the LoRaWAN packet in a format that is compatible with TTN Mapper. code, programming has been slightly tricky, but on Ubuntu the following works for me:
sudo apt-get install stm32flasher
cd
pio run
<move BOOT jumper on RAK811 board, plug in usb>
stm32flash /dev/ttyUSB0 -j
stm32flash /dev/ttyUSB0 -k
stm32flash /dev/ttyUSB0 -e 0 -w .pioenvs/rak811/firmware.bin<if any of the above commands fail, unplug and plug back in until it works>
Without a doubt. What kind of device do you want to connect?
Hi Russ
I’m trying to connect a ultrasonic sensor, I think I got vcc and ground, but just need 2 pins for trig and echo.
will the following pins work?
pinMode(PA1,OUTPUT); // Physical pin PA1 on the board ?
pinMode(PA15,INPUT); / Physical pin PA15 on the board ?
digitalWrite(PA1,LOW); // Pin PA1 | LOW is off / HIGH is on ?
digitalWrite(PA15,LOW); // Pin PA51
Thanks!
All these pins are brought out to the 10 pin headers on one side or the other.
All are GPIO.
All are 5V tolerant.
PB12 and PA1 are also ADC inputs
PB12 1 available
PA8 4 available
PB3 8 available
PB5 9 available
PB2 6 available
PA1 7 available
PA15 is used to control power to the GPS.
1 Like
Awesome
Thanks for the info…
1 Like
Has anyone tried RAK811 on mbed?
https://os.mbed.com/
In MBED release 5.8.2 RAK811 support was added.
But maybe that is for a separate thread, will add one when I have time to look at this.
https://os.mbed.com/teams/Semtech/code/LoRaWAN-NAMote72-Application-Demo/
Anybody tried using the board without an external active GPS antenna? I did, and got no GPS fix at all.
My goal for today is to design a 3D printed case for the tracker, holding an 18650 battery and the tracker together. I dropped my tracker and bent the antenna’s SMA connector. Gotta protect the poor thing if I’m going out and about with it!
Hi @OlofAst, I tried the original RAK811 board (no GPS) and needed to post a question on the mbed forum - https://os.mbed.com/questions/81016/LoRaWAN-support-for-MTB_RAK811-target-in/