General Discussion

I have been buying all the parts I need on amazon, though it takes around 2 weeks to arrive.

@mrhutchinsonmn a single rs485 connection can use the MySensors protocol, just as a single nrf24 can.

@alf none of the smaller sensor will do actual pm10. The intergration time would be way to long to actually measure actual pm10 sizes reliable. They all calculate it from the measured pm2.5 values.

I'm planning to use this: https://smile.amazon.com/Chapin-10027-48-Ounce-Industrial-Acetone/dp/B00C4NQSQ6/ref=cm_cr_arp_d_product_top?ie=UTF8 or this: https://smile.amazon.com/gp/product/B07ZZGWJ61/ref=ox_sc_saved_title_1?smid=ACTB8CBED46SR&psc=1 for rising with acetone I plan on using this: https://smile.amazon.com/gp/product/B08B3C2PM3/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1 or this: https://smile.amazon.com/gp/product/B005Z4RGQW/ref=ox_sc_saved_title_2?smid=A29JIFH4ZXPNL8&psc=1 for rinsing with IPA. I'm sharing the info because it's not always easy to find spray bottles with the right kind of chemical resistance. From what I've read, the usual advice for mechanical sprayers is to empty the container immediately after use because even with Viton seals and gaskets, very often "resistant" does not equate to "unaffected." For instance, LDPE ziplock bags may be able to withstand acetone for a while, but eventually the acetone will break through. Likewise, I used to think that nitrile gloves were fairly resistant to most chemicals, but then I noticed that acetone passed through them quite quickly. Likewise, nitrile gloves would be a poor choice for handling methyl alcohol. According to this handy chart, the best type of glove for both acetone and methyl alcohol (as well as IPA) are butyl gloves: https://www.augusta.edu/services/ehs/chemsafe/PDF files/gloveselechart.pdf As it happens, I picked up a pair just recently as PPE for use with, before, or after an ultrasonic PCB cleaning. However, last week I visited one of the big box hardware stores and their entire inventory of chemical resistant gloves was wiped out, so be sure to plan ahead.

As promised, what I found so far: the following dockerfile yeilds a usable cross-compile environment, provided you use it with a Makefile. FROM ubuntu:xenial RUN apt-get update \ && apt-get install --yes \ vim \ build-essential \ git RUN git clone https://github.com/raspberrypi/tools RUN git clone https://gist.github.com/3873805.git /build WORKDIR "/build" CMD ["/usr/bin/make", "CC=/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc" , "HelloWorld"] # Seems I need a real makefile for the above to work. For cross compiling mysensors to work, hoever, you also need to properly seed the variable in configure, for it to work correctly. This is where I left off. Sources: https://stackoverflow.com/questions/18007326/how-to-change-default-values-of-variables-like-cc-in-makefile https://bitbucket.org/mitchallen/pi-hello-cross-compile/src/master/ https://desertbot.io/blog/how-to-cross-compile-for-raspberry-pi https://github.com/mitchallen/pi-cross-compile/blob/master/Dockerfile https://github.com/mysensors/MySensors/blob/development/configure https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin https://www.raspberrypi.org/documentation/linux/kernel/building.md https://www.mysensors.org/build/raspberry

@172pilot said in Good thing mysensors has non-repeatable encryption....: @NeverDie Is a signing chip really necessary? If the packets are truly encrypted, and the hack you're trying to foil is a simple replay attack, I would think that including a simple incrementing counter into the message would do it. All the receiver would have to do is to only accept decrypted messages with a counter number GREATER than the last one it received. This should be simple to do if the encryption/decryption is already considered relatively secure? I think the answer is probably yes. Today. At this moment. At least for me and probably you. I mean, one could reasonably ask: why bother with having better security than my garage door opener? But as cracker tools become more prevalent, who knows what's coming next? It's not just us against juveniles and thugs, it's us against whatever weapons juveniles or thugs can download or buy ready-to-use from kickstarter (or aliexpress for cheap soon thereafter).

That worked for me. Thank you!

@mfalkvidd was part of the sketch. I could see right away that sleep did not work :)

@mrhutchinsonmn no prob! Glad I could help.

Thanks for explaining @mrhutchinsonmn

@ady_e_n Presumably a low current DPDT switch. Since I have them anyway I'd be using a latching DPDT signal relay fired by two logic level mosfets controlled by two pins, hence emulating the switch itself with no running current. The relays I have are NEC EE2-3TNU around 7mm thick and 9mm tall, 5v version should be available if that is your logic voltage level. If space permits you could hot glue the relay to the board on it's side with the mosfets/resistors/3 pin control mounted onto it's base, hard wired to the original switch pads. ;)

@eiten support for multiple radios is a new feature, only available in the development branch and not well documented yet so no surprise you weren't aware of it.

@cloolalang Actually, I'm tempted to try the SX1280. It's a lot more different: https://forum.mysensors.org/topic/11265/second-setup-choosing-a-radio/34?_=1595815545926 It looks as though a "good enough" test drive library may possibly already exist: https://github.com/StuartsProjects/SX12XX-LoRa The same person range tested it and also did a thoughtful review: https://github.com/StuartsProjects/SX1280_Testing Paraphrasing, he says it lends itself to a more simplified programming style than the highly register centric approach of the SX127x's. Spoiler: he proves a range of 40 kilometers transmitting at just 4dB. He estimates a range of 200 kilometers should be possible. Impressive for such a modest little module: [image: IMG_2517_Reduced.jpg] Sounds interesting!

Has anyone bought a PineTime by chance? They are really progressing quickly, with OTA support and everything.

@scalz Thanks.

@cloolalang said in LoRa/RFM95 - Testing long range PHY settings - Findings: w the SF 12 long payload messages pass! I tested various SF and BW and coding rates, I decided on the following for the "long-range mode". Typical use will be point-point mode, or gateway to 2 or 3 nodes max, no repeaters. Horizontal polarised yagi antennas. MY_RFM95_FREQUENCY 433237500ul (its 1MHz away from my co-located standard mode gateway frequency and other local ISM users). RFM95_MODEM_CONFIGRUATION RFM95_BW62_5CR45SF4096 (Typical time-on-air is around 4000ms. MY_RFM95_ATC_MODE_DISABLED (to reduce traffic). How is testing going on this? I'm interested to know what sort of distance you can cover, I'm planning on some long range sensors to be deployed on my farm. I'm not quite gettting the range I would like. Here is the radio config in my current setup, but I will definitly look at some of the additional config that you have. #define MY_RFM95_FREQUENCY (RFM95_868MHZ) #define MY_RFM95_MAX_POWER_LEVEL_DBM (100) #define MY_TRANSPORT_STATE_TIMEOUT_MS (3*1000ul) #define RFM95_RETRY_TIMEOUT_MS (3000ul) #define MY_RFM95_MODEM_CONFIGRUATION RFM95_BW125CR48SF4096 As a matter of interest has anyone used repeater nodes with these sort of long range setups. I'm talking about distances over a KM with no clear line of sight. I've managed to get simple comunications working over the required distance using simple transmitter and receiver sketches (provided by heltec, to demonstrate their Lora Node) sending "hello" packets

@Sasquatch said in BATERY CHARGER CONNECTION ?: Tp4056 is linear regulator, very inefficient, look at spv1040 or spv1050 instead - MPPT tracking propper solar chargers. C-x b wiki.org -> Electronics <TAB> -> Components <TAB> -> Power -> C-u M-<RET> to create new sub-heading ("MPPT tracking solar chargers"), paste (Yank) useful info for future reference. :wink: