@hek I was able to add support for stream message types to the log parser but can't perform a pull request against the gist. Here is my diff analysis if you're interested in this small update.

I also made a subsequent one line change to correct the issue that @BoresExpress noted a while back.

@meach Configure is not seeing the = in your command line properly - so I'm assuming a cut+paste issue with character strings.

Ie. It's seeing the configuration option --my-mqtt-user=pi instead of --my-mqtt-user and a value of pi.

Try to retype that part of the command line manually and try it again.

A

EDIT: As an aside, I usually put my configure command line into a script and then just run the script. Handy when you come back to it 6-8 months later and wonder what configure options you used the last time you ran it.

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

As you can see, I wouldn't want the batteries to be any closer together than they already are, or they would likely short out between them. As it stands, they're firmly in place, so no worries for now. These kinds of placement tolerance issues are hard to vet in advance prior to building a prototype. The keystone datasheet gave no guidance at all on side by side positioning. If I were to do it over, I think I'd give it another millimeter or two of safety factor separation.

Add some Kapton tape to the sides of the terminals next to each other to insulate against accidents without making it more cramped.

I've recently been updating my nodes and gateways to use the latest version of MySensors. I've also recently acquired a handful of Sensebender Micros and set one up in the pool shed to test/play and get some outside temperature and humidity readings. A problem I found though is that I was getting some anomalous data readings which completely throws off my time period data - see the 24-hour chart below.

Solar flares perhaps? I ruled that out.

I set up a test last night before turning in for the night and ran it for about 18 hours. I've collected and compared the debug logs of my node with those of the Ethernet and MQTT gateways that I have and found that the node is sending a valid float value at all times but the gateways will sometimes receive something different.

Node Debug Data (stripped to just the sending of one of the sensors)

4935 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.6
5480 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.2
6891 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.7
8331 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.4

And corresponding receives from the Ethernet Gateway debug log

Jun 04 00:55:20 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:21.6
Jun 04 01:02:35 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=5,l=5,sg=0:1101633946
Jun 04 01:37:38 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.7
Jun 04 02:13:52 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.4

You can see that the data received changed payload type from P_FLOAT32 (pt=7) to P_ULONG32 (pt=5) !!!

Note that the graph above is from data collected by way of the MQTT gateway and as such doesn't specifically correspond to the debug logs above but I do see exactly the same flip of payload type in the MQTT GW log - though at different times from those in the Ethernet GW log

Now I understand that this is going to come down to noise in the radio transmission but it raises some bigger-picture questions for me.

1. How can I ensure that the data received by the gateway is specifically what the node sent?
2. Would using ACK and having the node confirm if what was sent was received correctly be a valid approach?
3. Would implementing message signing help in any way?

I'm at a loss on how best to ensure the integrity of the data being sent and collected. What are your thoughts?

Allen

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

0.4mm diameter Kester Rosin solder.

I'll put it on my list. After the Male/Female antennae discussion above, I'm sure I got my order wrong - so I'll have a new running list shortly when everything arrives. I checked my solder with a caliper since the dimensions are listed in Chinese: it is 0.6 mm so I'm not far away. I do like the feel the smaller diameter has in comparison to my larger solder so I'm sure 0.4 mm will even be better.

Yeah, I was using 0.635mm MG Chemicals solder previously, but I found I had to drown the radio modules in rosin flux afterward to eliminate solder bridges, etc. Perhaps part of the difference may be that Kester uses a different formulation for its in-line flux than MG Chemicals? I suppose that could also have something to do with it. So, maybe it's not entirely diameter, but having now worked with the two different diameters, my gut intuition is that the smaller diameter is helping.

Anyone else reading this having any opinions on the matter that they are willing to share?

I swear by the stuff in the picture below. It melts at a lower temperature(179 C) so, as an amateur, I feel safer keeping my iron at a lower temp and in place a little longer when I am working with IC's. I like that it's thin too as it is easier to control how much you apply. I have no issues with it, it flows well and doesn't create bridges (unless I use too much).

@Larson said in Most reliable "best" radio:

To extract the *.rar in Windows 10, I downloaded a utility program (WinZip 21-day trial).

7-Zip is an open-source alternative that will do the job equally as well. https://www.7-zip.org/

Well done, forging ahead, @Larson. I wouldn't jump straight to trying to program a bootloader just yet though, we need to finish confirming communication with the chip and then if/when we get that going, look at how the fuses are set.

Looking at your post here, I believe you got these 328p's from Aliexpress (or similar). Did the listing indicate whether there was a bootloader or not? Bare chips, should be factory set to operate on the internal 8MHz oscillator, so that shouldn't be the problem. How many did you buy?

Based on your results above, at this point, it would seem that one of the following conditions exists:

1. There are solder bridges (shorts) somewhere - need to test with a MM in continuity mode, each pin with all other pins. Some should be connected (GNDs for example), but most should not.
2. The connections from your USBasp to the chip are incorrect. Again, you should be able to check this with a multimeter in continuity mode.
3. The chip is dead. (Long live the chip.)
4. The fuses are set to require an external crystal that doesn't exist. I just tested this by setting the fuses on my minimal 328P setup (see picture below). The result of which is that I now get the same error that you are getting. This is not likely the case for you but it is a possibility.

Here's a pic I just did checking continuity between the MISO contact on the USBasp and the corresponding chip pin on a minimal setup 328P for reference. Disregard that my multimeter is indicating no continuity, (my son took the picture at a bad time as I was making/breaking contact), you'll get the point of the shot though.

Also, take a close-up picture of the board/chip and post it here for us to see what you've got going on.

Carry on.

AH

EDIT: to add the 4th possible condition.

@Larson said in Bootloading a barebones arduino:

Manufactures probably have to make assumptions on this and the prevailing one would probably be for a 16 Mhz crystal.

If it's straight from the factory, the fuses will be set to use the internal oscillator and there will be no bootloader.

Looking at your pictures, the chip is well aligned and in the correct orientation. If you're confident in your connections and the USBasp is working well with the Nano but not this chip, then I suspect that the chip was destroyed while being soldered. The fuses-set-for-external-clock possibility is very unlikely and probably not worth the effort to try to test/debug/rectify.

[Side note @NeverDie: I see that you used D20 and D21 to control the LEDs on board. You might want to make a note on the OpenHardware.io page that users will need to utilize either direct Port B manipulation or MCUDude's MiniCore to control those and no crystal can be added to this board (unless you hack the LED and resistor pads to do it).]

@Larson, as you have a few more of those chips, I'd suggest putting this one aside for now and trying again (I'm assuming you have at least 2 other copies of V001 boards as OSHpark tends to sell them in 3-packs). If you want to hold off for a bit to wait for that cool clamshell thing, you might also want to consider ordering the V003 boards while you wait so as to avoid the problem with the traces under the battery holders.

AH

There's a broken link in the reference for MY_OTA_FIRMWARE_FEATURE in the Configuration section above (https://www.mysensors.org/download/sensor_api_20#configuration). I believe the correct URL should be https://www.mysensors.org/about/fota.

@NeverDie I hit up Keystone Electronics for a 3D model of the battery clip (p/n 92) and then did a little work on setting up 3D models of 2 and 4 of them together - though the 4-piece model is based on the spacing of 16.8mm between centres. If you're interested, I'll share them in a Github repository, since I can't upload them here.

@Larson said in Bootloading a barebones arduino:

I'm now talking to the chip in CMD terminal.

Well done! Let us know how it goes from here.

AH

@NeverDie Jonathan Oxer a little while back went through a similar process with programming headers for ESP8266/ESP32 boards. He discusses some of the challenges and tradeoffs in his video(s).

My personal opinion on trying to shrink them down is to keep with pin headers and just make them smaller. It's easy enough to find 1.27mm pitch IDC connectors. Your JST connector idea is good too. In the end, this is mostly a target audience scenario, it seems to me. My most recent board (still working on it), employed Oxer's ESPFlash header but I kept it with a 2.54mm pitch package because I have a ~million headers with that spacing and I wasn't cramped for space. (pic below)

If it's board-to-board as in connecting a radio module to an MCU backplane, then it's more of a use-case and dealer's choice scenario, in my mind. Those Molex SlimStack connectors look interesting.

I don't know if that helps or if I'm blowing smoke in the wrong direction. Just adding my voice.

@NeverDie said in Most reliable "best" radio:

I suppose it's more or less a conventional custom-built bed-of-nails.

@Larson said in Bootloading a barebones arduino:

Manufactures probably have to make assumptions on this and the prevailing one would probably be for a 16 Mhz crystal.

If it's straight from the factory, the fuses will be set to use the internal oscillator and there will be no bootloader.

Looking at your pictures, the chip is well aligned and in the correct orientation. If you're confident in your connections and the USBasp is working well with the Nano but not this chip, then I suspect that the chip was destroyed while being soldered. The fuses-set-for-external-clock possibility is very unlikely and probably not worth the effort to try to test/debug/rectify.

[Side note @NeverDie: I see that you used D20 and D21 to control the LEDs on board. You might want to make a note on the OpenHardware.io page that users will need to utilize either direct Port B manipulation or MCUDude's MiniCore to control those and no crystal can be added to this board (unless you hack the LED and resistor pads to do it).]

@Larson, as you have a few more of those chips, I'd suggest putting this one aside for now and trying again (I'm assuming you have at least 2 other copies of V001 boards as OSHpark tends to sell them in 3-packs). If you want to hold off for a bit to wait for that cool clamshell thing, you might also want to consider ordering the V003 boards while you wait so as to avoid the problem with the traces under the battery holders.

AH

Well done, forging ahead, @Larson. I wouldn't jump straight to trying to program a bootloader just yet though, we need to finish confirming communication with the chip and then if/when we get that going, look at how the fuses are set.

Looking at your post here, I believe you got these 328p's from Aliexpress (or similar). Did the listing indicate whether there was a bootloader or not? Bare chips, should be factory set to operate on the internal 8MHz oscillator, so that shouldn't be the problem. How many did you buy?

Based on your results above, at this point, it would seem that one of the following conditions exists:

1. There are solder bridges (shorts) somewhere - need to test with a MM in continuity mode, each pin with all other pins. Some should be connected (GNDs for example), but most should not.
2. The connections from your USBasp to the chip are incorrect. Again, you should be able to check this with a multimeter in continuity mode.
3. The chip is dead. (Long live the chip.)
4. The fuses are set to require an external crystal that doesn't exist. I just tested this by setting the fuses on my minimal 328P setup (see picture below). The result of which is that I now get the same error that you are getting. This is not likely the case for you but it is a possibility.

Here's a pic I just did checking continuity between the MISO contact on the USBasp and the corresponding chip pin on a minimal setup 328P for reference. Disregard that my multimeter is indicating no continuity, (my son took the picture at a bad time as I was making/breaking contact), you'll get the point of the shot though.

Also, take a close-up picture of the board/chip and post it here for us to see what you've got going on.

Carry on.

AH

EDIT: to add the 4th possible condition.

Hi @GertSanders,

Do you happen to still have the Eagle project files from version 3 you created and shared on OSH Park? I'd like to add a set of pads for the mini smd version of the NRF24L01. If not, I'll just use the version 2 files from openhardware.io and try my best to recreate the changes you made between them.

Kind regards,
AH

@NeverDie Awesome. thanks.

@NeverDie In considering a version 3, please consider turning the via in the following picture into a through-hole. it would allow for easier connection of a reset pin if needed to program the 328p with a programmer.

@Larson said in Most reliable "best" radio:

I don't think I can reach the fuses if the 'target' chip doesn't have a bootloader. Do I have that wrong?

You can reach (read/write) the fuses with a USBASP regardless of whether there is a bootloader. If you have any troubles, shoot me a message in the chat or start a new thread somewhere and I'll help you through it.

@NeverDie said in Version 2.0 atmega328p test platform:

They're onlly there in case you don't have any interest in measuring current and, thus, don't care to install the 4 header pins or the header pin jumpers.

Thank you for providing this insight. I enjoy learning by trying to understand someone else's perspective. It's not always provided as clearly or freely as you have (and do). Very much appreciated.