OTA firmware updating is too slow..

[sundberg84]

@yd-kim - I had this issue as well, because the node and gateway was to close to each-other.
Try to move them apart some more if possible and try.

[yd kim]

Thank you for quick reply.
I moved it to downstairs. There is one door is closed. but seems not much different.
I put node into downstairs cupboard and close door but seems not much different.

Thank you. Looks like handling issue. probably too fast to handle in steam mode?
My node is 8Mhz 3.3V board and Gateway is 5V. Both are atmega328.

Thanks.
YD

[martinhjelmare]

@yd-kim

Firmware messages have longer payload than regular temp or similar sensor messages. If you don't have perfect communication you will probably experience dropped messages during OTA FW update even if you don't have that problem for normal operation.

[yd kim]

Thanks martinhjelmare,
Yes seems that happen to me however I have no idea why it happen.
I have added 10uF cap for NRF24L01 and another 470uF as well.
It happen when presentation when I load 9 sensors. I have to add wait(200) for each present() otherwise 4th or 5th fail.
Looks like there is no handshake or doesn't consider receiver capacity.
Is there any workaround to fix this?
Main issue is when it fails, seems wait about 5 seconds to send again. As long as it wait less than a second, it will help for this situation..

Cheers,
YD

[martinhjelmare]

I can post my test sketch for OTA FW updates that I used when developing support for it in pymysensors. It worked good on a SensebenderMicro 8 MHz. I think I made some adjustments to make the update more effective. I also found that it worked better with debug activated, which might be a sign that communication was not perfect. My guess is printing to serial slows down things just a little bit.

[yd kim]

It will be great. I also turn on debug..
It means driver itself is too fast to handle on atmega328??
If we can reduce delay when it fails,it will be great. 5 seconds is too much I guess.

[Anduril]

@yd-kim what bootloader are you using? I have similar problems with tekkas newest bootloader, but the older one works fine for me.

[yd kim]

@Anduril
Oh really? I did use MYSBootloaderV13pre.hex.
Can you let me know which one you use?
Thanks!

[Anduril]

yeah I tried with the V13pre.hex, but with that I had problems as you descibed. Also the serial upload didn't worked for me. So there was no reason to not use the old one wich was included in his beta of MYSController. That worked much better. Maybe you can find the old version on tekkas download site of MYSController.

[yd kim]

@Anduril

Thank you! Will try tomorrow and update on this post!

[Anduril]

just as an update, here the link to tekkas 'old' MySController with the old bootloader: https://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/2

[martinhjelmare]

I implemented a check for firmware update message in my modified SenseBenderMicro sketch, and alternative behavior in the loop if FW update is ongoing. This doesn't solve the problem of dropped messages, but could be good to speed up the update and don't waste time on sensor updates.

void loop() {
  if (fwUpdateOngoing) {
    fwUpdateOngoing = false;
    fwUpdateOngoing = wait(OTA_WAIT_PERIOD, C_STREAM, ST_FIRMWARE_RESPONSE);
  } else {
    normalFlow();
  }
}

void normalFlow() {
  // Short delay to allow buttons to properly settle
  sleep(5);

  int buttonValue = digitalRead(BUTTON_PIN);

  measureCount ++;
  sendBattery ++;
  bool forceTransmit = false;
  transmission_occured = false;
#ifndef MY_OTA_FIRMWARE_FEATURE
  if ((measureCount == 5) && highfreq)
  {
    clock_prescale_set(clock_div_8); // Switch to 1Mhz for the reminder of the sketch, save power.
    highfreq = false;
  }
#endif

  if (measureCount > FORCE_TRANSMIT_INTERVAL) { // force a transmission
    forceTransmit = true;
    measureCount = 0;
  }

  sendTempHumidityMeasurements(forceTransmit);
  if (buttonValue != oldValue) {
     // Send in the new buttonValue
     send(msg.set(buttonValue==HIGH ? 0 : 1));
     oldValue = buttonValue;
     transmission_occured = true;
  }

#ifdef MY_OTA_FIRMWARE_FEATURE
  if (transmission_occured) {
    fwUpdateOngoing = wait(OTA_WAIT_PERIOD, C_STREAM, ST_FIRMWARE_RESPONSE);
  }
#endif

  sleep(digitalPinToInterrupt(BUTTON_PIN), CHANGE, MEASURE_INTERVAL);
}

[Mark Swift]

This post is deleted!

[tekka]

@Mark-Swift I'm not sure I understood you right - can you explain how this applies to the bootloader?

[Mark Swift]

This post is deleted!

[manutremo]

Sorry to revive this old topic but I didn't find any other one that covered this topic.

I started implementing FOTA in all my nodes and was finding some low speeds as described on this topic. I then implemented the checks proposed by @martinhjelmare and they certainly helped :grinning: , although they are not yet perfect.

As I said I didn't other topics covering how to avoid the node from doing anything else while the FOTA is in place, not did I find any other examples on this web nor in the github mysensors examples folder.

Is this the only way to do this, or is there any other better way around since this was published?

[manutremo]

No wonder, I think I found the way... I found there is a function isFirmwareUpdateOngoing() in MyOTAFirmwareUpdate.cpp that seems to provide that functionality in a much easier way :+1:

[Mark Swift]

@manutremo please share your method so we can all benefit :)

[manutremo]

If I understood correctly, it should as simple as in loop:

if (!isFirmwareUpdateOngoing()) {
<do whatever>
}

but for the moment take it with a pinch of salt...

[Mark Swift]

If I recall I tried that, I seem to remember it only works for the sensebender board? Perhaps I'm mistaken though, it was over 1 year ago. @tekka, can you confirm?