My TTGO cannot connect with ABP to V3

I can’t get my TTGO to work on V3.
I generated new keys with ABP. Also filled in Cayenne.
the weird thing is that only a few messages come in in Live data, and are also forwarded to Cayenne, and become visible there as well.
But after that nothing comes in visible in Live data.
Every few hours it tries to restart the stream, but sees an error, which I can’t translate or identify.

nfo
21:06:46
Stream reconnected
The stream connection has been re-established
error
21:06:41
Unknown error
An unknown error occurred and one or more events could not be retrieved
info
17:29:02
Stream reconnected
The stream connection has been re-established
error
17:28:56
Unknown error
An unknown error occurred and one or more events could not be retrieved
info
14:27:30
Stream reconnected
The stream connection has been re-established
error
14:27:24
Unknown error
An unknown error occurred and one or more events could not be retrieved

info
Note: This meta event did not originate from the network but was generated automatically by the Console. It is not related to any end device or gateway activity.
Unknown error
The Console encountered an unexpected error while handling the event stream data. It is possible that event data could not be displayed (correctly) as a result. Note that this is an internal error which does not imply any malfunction of your gateways or end devices.
Raw event
{
  "time": "2021-07-24T19:06:41.131Z",
  "name": "synthetic.error.unknown",
  "isError": true,
  "isSynthetic": true,
  "unique_id": "synthetic.1627153601131",
  "data": {
"error": "TypeError: Error in body stream"
  }
}

Do i need to change the software wich worked on V2 ?

Red Herring - relaying data to Cayenne has no effect on the ability of a device uplink

Double extra large Red Herring - see the bold text I’ve highlighted and if you search the forum you’ll find lots of other people angling for this funny coloured fish.

Please use the </> tool when posting logs or code.

Which TTGO, which firmware, do you restart the device, have you asked to reset the counters?

“Which TTGO, which firmware, do you restart the device, have you asked to reset the counters?”

TBEAM-V22-1-1 yes restart new device in V3,
reset counters, i dont know what you mean ?

  void setup() {

  Serial.begin(115200);
 
  Wire.begin(21, 22);

  if (!axp.begin(Wire, AXP192_SLAVE_ADDRESS)) {
    Serial.println("AXP192 Begin PASS");
  } else {
    Serial.println("AXP192 Begin FAIL");
  }
  //! enable all irq channel

  axp.setPowerOutPut(AXP202_LDO2, AXP202_ON);
  // axp.setPowerOutPut(AXP202_LDO3, AXP202_ON);
  axp.setPowerOutPut(AXP192_DCDC1, AXP202_ON);
  axp.setDCDC1Voltage(3300);
  axp.setPowerOutPut(AXP202_DCDC2, AXP202_ON);
  axp.setPowerOutPut(AXP202_DCDC3, AXP202_ON);
  axp.setPowerOutPut(AXP202_EXTEN, AXP202_ON);

  ///axp.setLDO3Voltage(3300);
  ///axp.setPowerOutPut(AXP192_LDO3, AXP202_OFF);  //  GPS voeding uitzetten
  /*
    Serial.printf("DCDC1: %s\n", axp.isDCDC1Enable() ? "ENABLE" : "DISABLE");
    Serial.printf("DCDC2: %s\n", axp.isDCDC2Enable() ? "ENABLE" : "DISABLE");
    Serial.printf("DCDC3: %s\n", axp.isDCDC3Enable() ? "ENABLE" : "DISABLE");
    Serial.printf("LDO2: %s\n", axp.isLDO2Enable() ? "ENABLE" : "DISABLE");
    Serial.printf("LDO3: %s\n", axp.isLDO3Enable() ? "ENABLE" : "DISABLE");
    Serial.printf("Exten: %s\n", axp.isExtenEnable() ? "ENABLE" : "DISABLE");
  */
  /*
    Serial.print("DC1:");
    Serial.print(axp.isDCDC1Enable() ? String(axp.getDCDC1Voltage()) + " mv" : "DISABLE");
    Serial.print("  ");

    Serial.print("DC2:");
    Serial.print(axp.isDCDC2Enable() ? String(axp.getDCDC2Voltage()) + " mv" : "DISABLE");
    Serial.print("  ");

    Serial.print("DC3:");
    Serial.print(axp.isDCDC3Enable() ? String(axp.getDCDC3Voltage()) + " mv" : "DISABLE");
    Serial.print("  ");

    Serial.print("LDO2:");
    Serial.print(axp.isLDO2Enable() ? String(axp.getLDO2Voltage()) + " mv" : "DISABLE");
    Serial.print("  ");

    Serial.print("LDO3:");
    Serial.print(axp.isLDO3Enable() ? String(axp.getLDO3Voltage()) + " mv" : "DISABLE");
    Serial.println("  ");

    Serial.print("LDO4:");
    Serial.print(axp.isLDO4Enable() ? "ENABLE" : "DISABLE");
    Serial.print("  ");

    Serial.print("Exten:");
    Serial.print(axp.isExtenEnable() ? "ENABLE" : "DISABLE");
    Serial.print("\r\n");

  */
  axp.adc1Enable(AXP202_BATT_CUR_ADC1, 1);
  axp.enableIRQ(AXP202_VBUS_REMOVED_IRQ | AXP202_VBUS_CONNECT_IRQ | AXP202_BATT_REMOVED_IRQ | AXP202_BATT_CONNECT_IRQ, 1);
  axp.clearIRQ();

  if (axp.isChargeing()) {
    baChStatus = "Charging";
  } else {
    baChStatus = "No Charging";
  }
  /////  Serial.println("------------------------ " + String(baChStatus));

  //  if (bootCount < 5)  axp.setChgLEDMode(AXP20X_LED_LOW_LEVEL);
  if (ContinueGPSzendenAAN) {
    axp.setChgLEDMode(AXP20X_LED_BLINK_1HZ);
  }
  else {
    if (bootCount < 2)  axp.setChgLEDMode(AXP20X_LED_LOW_LEVEL);
  }

  //axp.setChgLEDMode(AXP20X_LED_BLINK_1HZ);
  //I don't think this board has a built in LED, other than the Charge LED, controlled by this:
  // AXP20X_LED_OFF,
  // AXP20X_LED_BLINK_1HZ,
  // AXP20X_LED_BLINK_4HZ,
  // AXP20X_LED_LOW_LEVEL,

  Temp_setup();

  gps_setup();


  //Increment boot number and print it every reboot
  ++bootCount;
  Serial.println("Boot number: " + String(bootCount));

  //Configure GPIO38 as ext0 wake up source for HIGH logic level
  esp_sleep_enable_ext0_wakeup(GPIO_NUM_38, 0); // zet ContinueGPSzendenAAN naar true

  //Print the wakeup reason for ESP32
  print_wakeup_reason();
  smartDelay(50);

  Serial.printf("Starting...\r\n");

  // LMIC init
  os_init();
  // Reset the MAC state. Session and pending data transfers will be discarded.
  LMIC_reset();
  //------------------------

  // Set static session parameters. Instead of dynamically establishing a session
  // by joining the network, precomputed session parameters are be provided.
  uint8_t appskey[sizeof(APPSKEY)];
  uint8_t nwkskey[sizeof(NWKSKEY)];
  memcpy_P(appskey, APPSKEY, sizeof(APPSKEY));
  memcpy_P(nwkskey, NWKSKEY, sizeof(NWKSKEY));
  LMIC_setSession (0x1, DEVADDR, nwkskey, appskey);

  // Set up the channels used by the Things Network, which corresponds
  // to the defaults of most gateways. Without this, only three base
  // channels from the LoRaWAN specification are used, which certainly
  // works, so it is good for debugging, but can overload those
  // frequencies, so be sure to configure the full frequency range of
  // your network here (unless your network autoconfigures them).
  // Setting up channels should happen after LMIC_setSession, as that
  // configures the minimal channel set.
  // NA-US channels 0-71 are configured automatically

  LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_DECI);      // g-band
  LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_DECI);      // g-band
  LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_DECI);      // g2-band

  // TTN defines an additional channel at 869.525Mhz using SF9 for class B
  // devices' ping slots. LMIC does not have an easy way to define set this
  // frequency and support for class B is spotty and untested, so this
  // frequency is not configured here.


  // Disable data rate adaptation
  // LMIC_setAdrMode(0);

  // Disable link check validation
  LMIC_setLinkCheckMode(0);
  // Select frequencies range
  //------------------------
  // Disable link-check mode and ADR, because ADR tends to complicate testing.
  // Set the data rate to Spreading Factor 7.  This is the fastest supported rate for 125 kHz channels, and it
  // minimizes air time and battery power. Set the transmission power to 14 dBi (25 mW).
  //This tells LMIC to make the receive windows bigger, in case your clock is 1% faster or slower.

  //If it is a timing issue indeed, then you could try to increase the value, like changing it from 1/100 to 10/100.
  //(Very large values, like even 100% might not be supported 5.)

  LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100);   //vergroot het RX2 window

  // TTN uses SF9 for its RX2 window.
  LMIC.dn2Dr = DR_SF9;
  //LMIC_setDrTxpow(DR_SF9, 14);
  ////LMIC_setDrTxpow(DR_SF9, 20); ////==============================
  //  Uplink moet op SF7 blijven staan, dan werkt de downlink op SF9 beter.
  // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
  LMIC_setDrTxpow(DR_SF7, 14); //LMIC_setDrTxpow(DR_SF7,14);

  Serial.printf("LMIC setup done!\r\n");


  // Start job
  do_send(&sendjob);

  if (bootCount > 2) sleeptimerInSeconden = (300 - TIME_TO_SLEEP);// zet de timer op 5 Minuten....
}
///// einde setup................_______________

Please refer to the documentation and search the forum for the uplink counter f_cnt to acquaint yourself with LoRaWAN fundamentals. Docs are linked bottom right of every console page.

Iets get back to the original question. That is unanswered. I have similar issues with a ttnmapper ABP enabled device. This runs fine in V2 but in V3 the same device (rn4583 btw) can take minutes or hours before V3 starts decoding the packets and yes reset frame counters is enabled.

To me this seems a bug. But I might be missing something.

That is something Elisa would call “A really big mess!”

I haven’t put it through a rigorous / scientific testing regime, but as far as I can tell, if I use the CLI to setup an ABP device with counter reset turned on from the start, I’ve no issues.

I think I’ve tried doing a manual entry which worked but entering all the frequencies is a bit of a mess, so I haven’t done that in months.

afbeelding

afbeelding

LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_DECI); // g-band
LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_DECI); // g-band
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_DECI); // g2-band

i entered all these freq. one by one with save in between.
then i colapsed and expand the network layer again. Then some freq. are set to “0”

There are more bugs possibly ? Or am i doing somthing wrong.
I am still a beginner. and this will not change i am afraid.

Nope, I can enter them by hand if I choose, I enter them, click save and it works. Just delete the zeros and enter the missing ones.

What firmware are you using? Are you setting reset counters? Do you have 32 bit counters set?

" Just delete the zeros and enter the missing ones."
did that several times. entered them all at once an then saved them.

afbeelding
repalced the zeros
afbeelding

end after colapse and expand again !!!

afbeelding
I am using Firefox, shhould i try Edge??

With Edge the freq stay in the list… So it is a Firefox problem??

I use Chrome for all my system admin work but occasionally use Safari as that’s my general purpose browser.

Generally the expand & collapse of a group of fields is a display only action and doesn’t interact with the contents so that is quite surprising.

Ok, but by using Edge i was able to insert the freq.
But i still do not see data in the tab live data.
I restarted the TTGO. Nothing

any suggestions.
The keys must be OK because i received some data at first.

It’s very likely to be the f_cnt starting from zero every time you restart the device when the server is expecting a higher number. This is a security measure to stop replay attacks. You can read about it in the documentation and change the device settings.

Or use OTAA which automatically resets the counters on join.

"when the server is expecting a higher number. "
So nobody can use ABP? Or what can do in the software not to start at zero? start at 100 or so?
OTAA did not worked for me, couldnt get joins. could not solve that problem.
There was no need to switch to OTAA, ABP worked perfect on V2.
security OK. I have a problem…

Is it this counter value that is send?
//Increment boot number and print it every reboot
++bootCount ;
Or is that counter generated by Lmic ?

I don’t have any problems with ABP on v3. See Disable Frame Counter Checks in V3 - #60 by descartes

So how will your device cope when you need it to hear a downlink - discarding OTAA isn’t a solution, it’s ignoring a problem

It’s not available anymore, TTI have moved on, TTS is bigger, smarter, more compliant, more robust, still free to use.

That’s nothing to do with LoRaWAN

In the tangential way that it’s part of the LoRaWAN spec, a fundamental part of it, and so LMIC needs to keep the f_cnt.

Frame counters are so fundamental that your apparent lack of motivation to go and learn about them but to throw questions on to the forum indicates a bit of a loss leader for all those trying to help you as we’ll all be answering questions forever.

Thanks for the insult. At 74 years i try to pick up a solution, and still trying to learn.
But thanks for your answers…

2 Likes

I’ve managed to get ABP working flawlessly with V3 on my little temperature sensor, but you will need to disable frame counter checks during your development stages. You can fin this checkbox by going to your end device page, then navigating to General Settings > Network Layer > Advanced Settings, then check the box that says Resets Frame Counters.

That way when your device sends 1, 2, 3, 4, 5, 6… 99, or 100 packets, the server isn’t expecting packet 101 to arrive after the device has lost power or has been reset, as the device will begin at 0 again.

Thanks

It was already checked.

[quote=“greensladenz, post:19, topic:50018”]
after the device has lost power or has been reset, as the device will begin at 0 again.[/quote]

so the device must send 100 packets wich do not show before the the counters get in sinc again?

If it’s already checked, it shouldn’t matter what frame count is sent as they’re ignored.

The default behavior is an expected incremental count, this prevents replay attacks.

It’s not an insult to point out that we keep saying the same things and nothing is changing - and it certainly wasn’t intended as one, it was definitely designed to try to get you to find out the background to the problem. I would have no knowledge of your age and it is totally irrelevant.

And here’s the issue - if you read the docs you’ll find out it’s not 100, it’s not a specific number, it’s the next number in the sequence, which could be 10,000 or 458 or 6,942 - so if you have a power cycle at some point in a years time, you could be waiting a very long time before the device catches up.

Is there on the console not a reset possible with a button. so both can start from scratch again. Just my simple mind thinking. :smirk: