sodaqmoja / sodaqone-universaltracker Goto Github PK

Perhaps you could also mention the following things about the LoRa frame contents:

• data is encoded in little endian format
• timestamp is in seconds, the 'epoch' starts at 1970-1-1 00:00:00
• the base unit of latitude/longitude is 1E-7 degree
• speed over ground is in units of 0.01 km/h?
• course over ground is in degrees (0..360)?

I'm having trouble with OTAA in my area, the JoinAccept message is not received by my SodaqOne. It would be nice to have the option to store the OTAA status in EEPROM and reload it on reboot.
Of course a configuration would be required that toggles this option, so it is still possible to start a fresh session if required.
AFAIK the following parameters must be saved in EEPROM:
AppSKey (save once)
FCntUp (save on every transmitted packet)
FCntDown (save on every received packet)

Note: I do not know how many times the EEPROM can be safely written, since it is emulated EEPROM. Does this mean it is effectively infinite? And does it take a lot (relatively speaking) of power to write to the EEPROM?

Steps needed:

• Get AppSKey from LoRa module (how?) after OTAA and store in EEPROM
• Track FCntUp (how?) and store in EEPROM after every transmit.
• Track FCntDown (how?) and store in EEPROM after every received message.
• On boot, restore AppSKey, FCntUp and FCntDown to the LoRa module (how?)

Anything I missed?

Hi! I've received the SodaqOne yesterday and with the pre-installed tracker and boot menu, it was really easy to get it up and running 👍

Most values I've been able to parse, but some of them I'm not sure if I understand them correctly:

Battery:

In the readme the battery voltage is documented as the value beween 3-4.5V. Does this mean the value defines the steps between 3 and 3.5V? So to get the voltage, I have to make the following calculation?

3.0 + (1.5/255 * value) = voltage

Board temperature:
Given that I'm getting values > 200 back, and my board is not on fire 😉 , how should this be interpreted? Should I divide the result by 10?

2016/07/31 10:16:03 topic: application/0202020202020202/node/0101010101010101/rx, payload: {DevEUI:0101010101010101 FPort:1 GatewayCount:1 RSSI:-51 Data:[195 179 157 87 89 229 60 64 56 31 190 47 229 2 5 0 1 0 100 5 3]}
decoded record: {DevEUI:0101010101010101 Time:2016-07-31 10:16:03 +0200 CEST BatteryVoltage:3.523529411764706 BoardTemperature:229 Lat:52.3780156 Long:4.8574398 Altitude:5 Speed:1 Course:100 NumSatellites:5 TimeToFix:3}

Many of us are using SCG as the availability of full gateways is limited or expensive for many.

I suggest that you should conciser adding a SCG mode to your code base...

1. A switch to set SCG in the menu
2. Ability to set the Channel to use
3. Use the SF that is now in the menu

Most of the code needed for this is in your code base now... The RN driver has the code to turn off channels.

Thank

Hi,

Can you please post the Arduino console or make a video of a successful OTAA connection? I am unable to get a successful OTAA connection using a MultiTech Conduit Gateway. Configuration for multi tech as follows:

{
        "lora": {
                "netID": "010203",      /* netID for beacon packets */
                "frequencyBand": "915", /* US="915", EU="868" */
                "frequencySubBand": 7,  /* Sub-band for US operation, 1-8 */
                "rx1DatarateOffset": 0, /* Datarate offset for mote rx window 1 sent in join response (0-3) */
                "rx2Datarate": 12,              /* Datarate for mote rx window 2 sent in join response (7-12) */
                "maxTxPower": 14,       /* Max Tx power (dBm), -6 to 26 */
                "frequencyEU": 867500000 /* center freq for extra EU channels (Hz) */
        },
        "udp": {
                "appPortUp": 1784, /* port for user-developed application use */
                "appPortDown": 1786 /* port for user-developed application use */
        },
        "addressRange": {
                "start": "00:00:00:01", /* address range used for mDots */
                "end": "FF:FF:FF:FE"
        },
        "network": {
                "public": true,    /* set to false for private LoRa network with mDots + Conduit */
                "leasetime": 0,  /* time until mDot join expires (minutes) or 0 for no expiration */
                "eui": "01:01:01:01:01:01:01:01",
                "key": "01:01:01:01:01:01:01:01:01:01:01:01:01:01:01:01"
        },
        "log" : {
                "console" : true,
                "syslog" : false,
                "level" : 30, /* error=10, warn=20, info=30, debug=50, trace=60, max=100 */
                "path": "/var/log/lora-network-server.log"
        },
        "mqtt": {
                "enabled": true
        }
}

I setup the lora tracker and when I am in reach of a good gateweay everything works fine.
however when I am in range of a single channel gateway (Sf12) the board tries to connect twice and then stops.

the board is using SF9 no matter what I change in settings.
and the retry option isn't working.

I plan to place the board on hard to reach locations. I need to make sure they retry at any failure.

Settings:

GPS
  GPS (OFF=0 / ON=1)         (gps=): 1
  Fix Interval (min)         (fi=): 15
  Alt. Fix Interval (min)    (afi=): 0
  Alt. Fix From (HH)         (affh=): 0
  Alt. Fix From (MM)         (affm=): 0
  Alt. Fix To (HH)           (afth=): 0
  Alt. Fix To (MM)           (aftm=): 0
  GPS Fix Timeout (sec)      (gft=): 900
  Minimum sat count          (sat=): 3
  Num Coords to Upload       (num=): 1

On-the-move Functionality
  Acceleration% (100% = 8g)  (acc=): 0
  Acceleration Duration      (acd=): 0
  Fix Interval (min)         (acf=): 1
  Timeout (min)              (act=): 10

LoRa
  OTAA Mode (OFF=0 / ON=1)   (otaa=): 1
  Retry conn. (OFF=0 / ON=1) (retry=): 1
  ADR (OFF=0 / ON=1)         (adr=): 1
  ACK (OFF=0 / ON=1)         (ack=): 0
  Spreading Factor           (sf=): 12
  Output Index               (pwr=): 1
  Lora Port                  (lprt=): 1
  DevAddr / DevEUI           (dev=): **********
  AppSKey / AppEUI           (app=): *********
  NWSKey / AppKey            (key=): ********
  Repeat Count               (rep=): 1

Misc
  Cayenne LPP (OFF=0 / ON=1) (cay=): 1
  Temperature Sensor Offset  (temp=): 20
  Status LED (OFF=0 / ON=1)  (led=): 0
  Debug (OFF=0 / ON=1)       (dbg=): 1

Good day,

i have a Sodaq one Version 2.
at the temperature it always reported a nice 20 degrees.

when i changed the getBoardTemperature function to bellow. it reports an rawTemp of -1
when checking the bellow page it shows an LIS3DE instead of an LSM303
https://support.sodaq.com/Boards/One/#summary
Is this device capable of measuring the temperature?

int8_t getBoardTemperature()
{
    setLsm303Active(true);

    uint8_t tempL = lsm303.readReg(LSM303::TEMP_OUT_L);
    uint8_t tempH = lsm303.readReg(LSM303::TEMP_OUT_H);

    // Note: tempH has the 4 "unused" bits set correctly by the sensor (0x0 or 0xF)
    int16_t rawTemp = ((uint16_t)tempH << 8) | tempL;

    setLsm303Active(false);
      #ifdef DEBUG
        consolePrint("temperature: ");
        consolePrintln(rawTemp);
      #endif

    return round(TEMPERATURE_OFFSET + rawTemp / 8.0);
}

not an actual issue. more a future request.

when the board runs on battery (or solar) you have to choose between outage. or long intervals.
when the battery runs empty the board will never get enough power for a strong transfer.
can we make the interval variable with the battery level.

the board register the battery minus 3 volt. (so we have a scale for 0v > 1.5v )
i suggest the follow calculations
1.6-[volt] *3000 seconds
this give us a scale from 5 to 75 minutes interval.
when usb power is present the board will always use the 5 minutes interval. but when external power is lost the board will use its power wisely.

i expect this would't be to hard to implement but the code of this tracker is above my level. :)

Hi,
I'm testing the Sodaq ONE v3. Currently it's configured for OTAA and ADR and set to send out an update every 10 min. ACK is enabled.

I've configured and joined it with Chirpstack which has been working fine.
After a while, the battery runs out, or gets very low. So it wasn't able to send out an updated properly.

I've now connected it to the console again and it currently shows this messaging:

Trying to join...
[wakeUp]
>> mac set deveui 0004A30B00EB5E28
[expectString] ("ok") .--> "@�2BB�@�2BB�@�2BB�@�2BB�@�2BB�@�2BB�@�2BB�@�2BB�@�2BB�@�2BB�@�2"
Failed to reconnect! Hardware-resetting the modem and scheduling a retransmission (if applicable).
[hardwareReset]
[expectString] ("RN") .--> "RN2483 1.0.5 Oct 31 2018 15:06:52" found a match!

I believe the mac set deveui returns something wrong and it feels to me like it's just returning a wrong bit of memory.

Has anybody seent his, is there a fix for this?

Hello,
i am trying to decode UniversalTracker V3 payloads that are received by:
mosquitto_sub -h staging.thethingsnetwork.org -t '+/devices/+/up' -u *********** -P '*************' -v

The payload looks like that:
LYNdn/wjVo54W5/4+EIMyn3USIrX

Using my payload, the scripts offered in forum are failing:
http://forum.sodaq.com/t/interpreting-payload-data-from-the-sodaqone-universaltracker/374/9

I passed an other payload from an unknown user to the python script:
wsqDV/8nCidFHLMzFwW+AQQAMgQO
This payload decodes perfect.
I am stuck!
Please help :-)
Matthias

pi@raspberrypi:~ $ echo $payload poLJlK7MQNIpB+POeTdWS3ytJx+y pi@raspberrypi:~ $ python ./sodaq_tracker_2.py $payload Traceback (most recent call last): File "./sodaq_tracker_2.py", line 37, in <module> print (parse(arv[0])) File "./sodaq_tracker_2.py", line 18, in parse values["time"] = datetime.datetime.fromtimestamp(parsed[0]) ValueError: timestamp out of range for platform time_t

pi@raspberrypi:~ $ echo $payloadGood wsqDV/8nCidFHLMzFwW+AQQAMgQO pi@raspberrypi:~ $ python ./sodaq_tracker_2.py $payloadGood {'sats': 4, 'temp': 39, 'course': 50, 'lon': 8.5406643, 'volt': 255, 'time': datetime.datetime(2016, 7, 11, 18, 35, 14), 'lat': 47.4294026, 'alt': 446, 'speed': 4, 'ttf': 14} pi@raspberrypi:~ $

I could not change the device's SF (for example to SF12 = DR0) by sending a link ADR request. I can see that the device even responds this MAC command with its next uplink message and confirms the datarate with Status = 6 (that means power ack and datarate ack). However the initial datarate from OTAA join is still used.