@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/

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.

Figured out that I misunderstood the purpose of this directive. I was thinking (had assumed) that it was showing more verbose information through the serial output for firmware OTA update traffic. Once I looked at the description for it, it was clear that it is intended more as an alternative to MY_DEBUG - as in don't send debug output to the serial but send it over-the-air instead. I was declaring both and they conflict.

EDIT: saying they conflict is inaccurate. The problem was in how I was using it (inappropriately).

-- Allen

I've only just started playing with KiCad 6.0 myself. I'm liking it too. I picked it up in order to have a closer look at @m26872 's contribution of KiCad design files from 2015 (using KiCad 4.0 RC2!) for their Slim 2xAA Battery Node.

They seemingly created the zip file by simply creating a Zip file of the folders that contain the project. That may be the best approach.

I've been able to open it and although had some challenges remapping the libraries, as they were changed significantly between 4.0 and 5.0, I've been able to have a good look and have plans to change the orientation of the ICSP header to the edge of the board, if I can learn enough to do that.

As a test of that theory and as a contribution back to the community and @m26872 I tried to upload my copy of the design files in KiCad v 6.0 format but ZIP files are not allowed anymore.

@mfalkvidd Thank you - MY_DEBUG_VERBOSE_OTA_UPDATE does look like it's exactly what I was looking for. Further looking into the code here though, it would seem that it gets defined automatically if we define MY_DEBUG.

Turn it around, when we define MY_DEBUG, we should see verbose FOTA (+ Core, Transport and Gateway) information in the serial log output.

I'll attempt some more testing tonight to see what I can see.

@NeverDie I thought your turnaround time was decent compared to mine. It has been taking up to 3 weeks for me to get mine from OSHpark. The last fab I ordered, I priced it out at PCBway but they were $29 versus OSHpark's $16. I do find though that within days of sending it off for fabrication, I'm making improvements to the design and kicking myself for placing the order too soon.

@NeverDie, Thank you.

@NeverDie said in Most reliable "best" radio:

I widened the separation between the batteries, and now the clips aren't at risk of shorting against one another.

It's looking good! I'm curious, how far apart are the battery clips now (center-center)? I noted on the original board layout it was 15.62mm. I'm guessing it's about an extra 3mm based on the lines of the silkscreen and the size of the mounting holes you added.

Also, an off-topic question for you - I believe I read in a thread somewhere recently (not sure which one though) that when adding a USB port you prefer USB Mini. Which footprint do you like to use and where do you source them from?

@NeverDie said in Most reliable "best" radio:

@alphaHotel Reporting back: I received them, and mine did not come with any antennas.

That's as I expected too because of the lack of any photos in the listings. Thanks for confirming, it's good to know. I do have a handful lying around from old WiFi routers as you mentioned.

@Larson said in Most reliable "best" radio:

Yes, I think I got your version from Github. I will learn how to send a pull request. Cool, so this is how collaboration works? I'm new to this.

Please don't add to your personal learning curve to create a pull request. It's not that important, at all.

@Larson said in Most reliable "best" radio:

I shrank the frame of the board to minimize the interference with the TestPlatform neighboring pins

Nice! How wide is that VCC trace/plane at its narrowest point now?

If you got it from Github, are you able to send me a pull request?

@NeverDie said in Most reliable "best" radio:

Adafruit's Clue device uses the KLJ-5030, which is 5mmx5mmx3mm:
At higher cost I notice that there also exists a KLJ-4020, which is 4mmx4mmx2mm

Yikes! Watch out for those shipping costs. Check my math, 4mm x 4mm x 2mm x 20 pcs = 640 cubic mm = 0.640 cubic cm = 0.0391 cubic inches, from China for $72 shipping? They must weigh a ton (or a tonne). LOL!

Seriously though, good find! I think I'll keep shopping around for a better price though.

More for my own future reference than anything else, the distance between the two AA battery clip mounting points is 15.62mm centre-centre.

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

On your recommendation I'm looking for this solder as well. For those who follow this thread I found it here.
The solder diameter that came with my Chipquick SMD1 Removal kit was enough for one job, maybe. The linked 4 Oz. supply will last some time for me.

That's not quite the same stuff. What I use has a small amount of silver content in the alloy. You can find it here at Mouser.com. The smallest size they have though is the 8oz which is basically, a lifetime supply for me at least.

UPDATE:

• I've created a Github repo for my version of the nRF24L01 adapter board.
• I've created an OpenHardware.io project for it referencing the Github repo to extract/generate the files.
• My OpenHardware.io project is being reviewed before it is published. When its available you'll find it at https://www.openhardware.io/view/32973/nRF24L01-Adapter-Board-AH.

I've done it this way partly as a test as it ties back to this thread about sharing a complete set of KiCad design files. I'd appreciate any feedback on being able to open and edit the files. Also, feel free to submit a pull request as a test of collaborating with Github and KiCad but only if you're interested in the results too.

Edit: OpenHardware.io project is now available publicly.