Two Moteino, same sketch, two results?

[drsprite]

I have two Moteino USB running the VPTools weather station WxReceiver code. On one Moteino it counts the lost packets accurately. On the other Moteino it counts every packet as a lost packet - even if it's received.

This section in the sketch is where the lost packets are incremented, and this variable threshold has a direct affect on how to classify the lost packet. If I change that timer value from 5000L to 7000L it sort-of fixes my problem on the 2nd Moteino. Lost packets are a little more accurate except they're doubled. So for every 1 lost packet, the counter shows 2. So something is still a little sideways and I don't know what.

Since both of my Moteinos are running the same code, I'm to assume it's a hardware problem? I'm afraid to touch my working Moteino since it's in "production".

I'd like to be able to rule out bad hardware, which means uploading the sketch again to the working Moteino. Since it's been a year since I've uploaded to this Moteino I have a bit of concern breaking it because it's my primary receiver.

1. Is it possible that there's a hardware issue that would be causing this? Maybe a change in clocks or something?
2. Is it possible to download and restore a bin of the working Moteino's code from it's memory to have as a backup? That way I can flash the sketch and if it's bad then I know it's code and upload the bin for quick recovery.

I can't pretend I know all of the ins-and-outs here, I just know that I'm running the same code on 2 devices and have different results. Looking for some insight.

Thanks

[Felix]

Both have "same code" is actually a broad statement, the actual code you compile may be the same but the result may be different depending when and how it was compiled. Especially considering that "same code" 1 year ago may have been running with different versions of libraries and arduino versions etc.
Different behavior could be a variety of things, from changes in libraries to different compiler optimizations.

Hardware wise - you'd need to compare more than just 2 units to rule that it's a hardware problem. But I doubt it is a hardware problem. And they absolutely have to be identical in every aspect, including code, not 1 year apart.

You can back up the content of a chip with an ISP programmer. Moteinos have fuses set to allow this.

If they are running the same code but compiled at different dates, I would read the BIN of the working chip and load it on the second, and compare it like that. At that point hardware faults could be considered.

[drsprite]

Thanks Felix. Interesting point about the library updates. I hadn't thought about that since I touch Arduino (and Moteino) about once a year, and this is the time of year I guess. My Arduino IDE keeps telling me to update libraries and boards and I keep ignoring it for this same reason - I don't want much to change. But maybe I did click Update previously that I don't recall doing.

So looking at that GitHub sketch, most of the files it references are included in that repo. Except for the Moteino board and the LowPowerLab SAMD board packages. As well as references to Arduino.h, SPI.h, EEPROM.h, Wire.h, avr/wdt.h. I guess I need to see if I can downgrade those? I'm not looking to re-write the sketch's code, just looking for that snapshot of files and firmware from May 28, 2018 so that I can replicate what I have already.

Like I said, I don't know much about this. Do you have a guide on the Fuse and download/upload procedure that I can use to download/upload the data off the chip? I could at least have a backup of it and try it on both Moteinos as a crude test.

Thanks again

[Felix]

If you have another 2 units to test, just compile your latest code and upload to both. Then you know if it acts the same or not. Its just a matter of identifying the shortest path to resolution (divide and conquer the problem to small pieces that are easy to work with).

RE ISP - I dont have a guide, because there are unlimited such guides on the internet, depicting how you might do it with an actual programmer, or an Arduino, and using Atmel Studio or avrdude etc. You dont have to change any fuses. You only have to use an ISP programmer to read the memory content (it will also read the bootloader), and write that to a new Moteino. Ensure you dont change fuses or you can brick the AVR.

[drsprite]

Yeah that's my concern. I have avrdude, but I don't want to brick anything. A simple Google brings this up but I don't have the gall to try it without confirmation.

Code: [Select]

avrdude -p m328p -P usb -c usbtiny -U flash:r:flash.bin:r

I only have 2 Moteino USBs, not 4, so stuck with what I've got.

[Felix]

ISP programming can be pretty intimidating, more so the first time you try it!
I would recommend getting an ISP programmer, there are many out there that will work.
Having only 2 units to work with also makes it a little hard to experiment.

[HeneryH]

Is there any chance the boards have different radio modules by accident?

[drsprite]

Is there any chance the boards have different radio modules by accident?

Good question - I hadn't thought about that. What I am noticing is that the radios look the same, but it's a MoteinoUSB R6 (reliable one) vs the R7 (my less-than reliable, but not broken) one.

I had thought I had another R6. My guess is a change in something is making the sketch act differently?

[Felix]

I had thought I had another R6. My guess is a change in something is making the sketch act differently?

Not really, essentially R6 and R7 are the same.

[drsprite]

Ok, thanks. I'm a bit stuck at this point. My Rx stats have gone from 98-99% on the R6, to 67% on the R7. I could keep messing around with this "lost threshold" variable that's in the sketch and hope to find the sweet spot.

[Felix]

Yes, stuck if you are afraid to reflash the "reliable" one.
You need to get to an even starting point, and evaluate from there, ie flash both with same code.

[drsprite]

Yes, stuck if you are afraid to reflash the "reliable" one.
You need to get to an even starting point, and evaluate from there, ie flash both with same code.

Yeah absolutely afraid to reflash my "reliable" R6 one 

Another Moteino user on the wxforum mentions they are experiencing similar lost Rx and Tx packets with newer revisions of the board. It could be software related but I still wonder about the hardware. Would the transceiver be the same between revisions?

[Felix]

Would the transceiver be the same between revisions?

Yes, safe assumption.
I will dub this software bug, until hardware proven guilty. It usually goes like that.

[drsprite]

Also FYI your shop still says R6 for the MoteinoUSB. I bought this one in January and (just realized it was an R7). I think the shop description should be updated.

[Felix]

Also FYI your shop still says R6 for the MoteinoUSB. I bought this one in January and (just realized it was an R7). I think the shop description should be updated.

Likely just going back to R6 after the current batch is done. The only difference is cosmetic, and there is a 0ohm resistor added, otherwise it's basically an R6.
It was an attempt to lower current leakage through the FTDI connections but that proved to be a non issue.