Hardware

@Aymeric are you sure the node isn’t sleeping for 5 seconds? WUP=-1 means it woke up by timer. Check using an external clock, and/or turn on timestamps on the Arduino IDE log.

we’ve been using Triton detectors at my school for a while now, they catch both nicotine and THC vapor fast and it sends an alert right when someone vapes, even picks up small amounts. it’s probably the closest thing you’ll find for what you need.

@buxtronix thanks for the effort! Why not make a PR? 433MHz is a quite unique value proposition of MySensors. I'd recommend a quick search through the open issues on MySensors github, maybe some CC1101 support was requested already. In any way, I'd encourage to raise a PR to the development branch. Who knows, if we get some people engaged, maybe we can release a new official version of MySensors with improved hardware support. Thx, Dirk.

Hello I still didn't figure it out exactly, what is the issue with LGT8F328P and arduino, but for start, it can work, if you define 4x faster baud rate. So I define MY_BAUD_RATE 76800 and connect terminal with 19200, and it works. LGT is started in 8 MHz by default, and it looks like this is not corrected with mysensors. But this only helped for serial port, because later I had issues with DHT library timings. If I later change speed to 16 MHz and start serial port again, it works as expected: noInterrupts(); CLKPR = 0x80; CLKPR = 0x01; interrupts(); Serial.begin(19200);

as I experienced, MQ sensors are not really gaz sensitive, they are more particle size sensitive when hot enough and when not totally scrap. I would not rely my life on them, if you have an alcool spray use it around and any MQ will to go the sky...

Hi everyone, bumping this thread because I could read some of you were interested in packet loss (@NeverDie and someone else) and my findings could help fix it partially or completely via software. It's certainly a hardware problem, though I can't figure out if it's due to the components physical positioning, the power supply, or both (and/or more issues like wiring, proper PCB traces, etc). Also, even the same modules from the same manufacturer, say EByte E01 PA+LNA modules in my case, have shown different performances, so it might be something bound to the variability of the SMD components used as well. Let's get straight to the point. I am the developer of rf24tunlink, a radio network bridge which uses primarily nRF24 modules. During R&D, I found that around 30% of packets from my modules were dropped due to a couple corrupted bytes, which was constant even in close range. That does indicate a hardware problem already, but the distribution of the bit flips is an even stronger indicator. [image: eb505750-d741-45b2-aba1-57d26913c786] All flips are in the first bytes! You might be getting at least one flip in most packets, resulting in ALL of them being dropped automatically because this invalidates the CRC. In this scenario ShockBurst can fail, or you might get duplicates, might not get ACK payloads or simply get a slow link because the same packet can be sent up to 15 times with a wait between each retry. Not coming here unarmed: how to fix it? Easy in principle, you: Disable CRC -> ShockBurst off, no ACK payloads, essentially your module will be RX only. Implement RS ECC: sacrifice just enough bytes to fix all the corrupted bytes. (in my case, 2/32 was enough!) That's how I turned a 30% packet loss into a 100% flawless reception, see this result: [image: 43bcccb9-9b9d-4ae8-ac4b-c9ed1f8fc320] There is more to it, as the link gets worse, of course this situation also gets worse. Finding out how many errors are in a packet can help you estimate signal quality and potentially take preventive measures. Now, if you only care about sending a specific packet, you either receive it or not at all and that's it. But if you want more like I did, then things get more complicated. In this case I wanted a full duplex link -> a second pair of nRF24 modules was mandatory I also wanted to send network data (iperf, ping, ssh, realtime video, audio, telemetry, control, anything really) -> frames needed to be split into radio packets, sent, corrected and stitched back into a frame. That is a HARQ algorithm. After all of this, I could get a usable network speed of 1.2Mbps (determined via iperf). Used a Pi 4, Pi zero 2 W and 4 nRF24 PA+LNA modules. You could use this same metric to evaluate your components, some modules could do better and some could do worse. Would be cool to fix this hardware for all and get closer to that 2Mbps max speed. Some people declared a speed of 1.7Mbps and I have seen a 1.5Mbps peak during development, so there is definitely room for improvement. [image: 1bd38d37-7a09-49e1-b92b-7d0838d1c436]

@OldSurferDude Thanks! I didn't touch the Arduino IDE for a while and forgot that the MYSBootloader doesn't come included in the Mysensor's library... My bad. Thanks for the link! I should had searched first... I use the OTA feature since 2017... It works well. So well that I forgot how to load the bootloader... Regards!

Check out My Projects to see what can be done. Then decide what you want to do. Come back here for help -OSD

Gawd bless ya @OldSurferDude , that just about answered every question I have to date, I especially thank you for indicating whether the item named is a software or hardware product. On reading into the Cerbo GX capabilities I was very impressed with its sophistication and, just as you said, I will have to break the complicated parts down into bite-sized pieces and build from there. It started with an idea for a project, essentially to take data on battery state of charge (SoC) from the Cerbo GX and use an Arduino Nano or ESP8266 to build a strategy so that I would have sufficient hot water in the morning, consistent with having enough battery power left in the evening. Only on further inspection did it occur that the Node Red software built into the Cerbo GX could do this for me...and thus the possibility that a wireless hot water temperature sensor (transducer) could be fabricated to feed that data into the Cerbo GX; hence my path to here. I've dabbled in programming in C, mainly through the Arduino IDE, and in a previous life part of my work involved programming PLCs for industrial automation, so I am somewhat familiar with 'tech', but I lost interest once most systems seemed to go Windows based. In the intervening years the 'tech' has moved on apace and has left me behind, which is why I've struggled to follow the jargon, akin to trying to fit the second piece in a large jigsaw puzzle. Once the fundamentals are there I'll catch on. So please, kind contributors, be tolerant of the silly questions we newbies ask, we won't always be newbies, and I'll be back for sensors stuff once I've tamed the red-hot node and sorted out my LBQTTs Best wishes....MM

Great project! With some guidance, KiCad and AVR will click again!

It probably has to do with fewer people buying them once summer ends, so companies might lower prices to clear out stock before winter.

Just wanted to say thanks for this, it is still relevant and useful six years later !

@wrendral said in "Remote Irrigation with LoRaWAN: LM27313 Challenges and PCB Design": I will go with a Li-Po Battery type: 304048 3.7V 1200mAh Might work, but maybe the internal protection will trigger with the high current peaks. I'd suggest you plan a 0 Ohm, (2512/THT) resistor as R2 and then replace it with a 100Ohm/1Watt if the protection triggers.

I have success! (oops, that's suppose to be Timer1) I only sample for 1/60 of a second. What I did was to back up all the timer registered I used and then resorted them after I was done sampling. (As opposed to initializing the registers in setup and then starting the timer when needed.) Now I have a Nano sampling the data and sending it to a MySensors Gateway on an RPi3B+ which then sends it to an MQTT broker runing on an old laptop. Also running on the laptop is Home Assistant running inside of VirtualBox. If MySensors does use Timer1, it appears that restoring the registers allows it to be shared. //------------------------------------------------------ISR ISR(TIMER1_OVF_vect){ // interrupt service routine for overflow TCNT1 = TimerPreloadValue; // must be first line! starts the timer counting again digitalWrite(TRIGGER_START_SAMPLE_PIN,HIGH); samplesVolts[--sample]=analogRead(VOLTS_IN_PIN); // decrement before capturing samplesCurrent[sample]=analogRead(CURRENT_IN_PIN); digitalWrite(TRIGGER_START_SAMPLE_PIN,LOW); if (!sample){ // count down to zero digitalWrite(TRIGGER_START_SAMPLE_PERIOD_PIN,LOW); // indicate that sampling is complete samplingEnd = micros(); TCCR1B &= 248; // turns off timer } } //------------------------------------------------------sampleOneCycle void sampleOneCycle(){ // back up timer registers uint8_t TCNT1_b = TCNT1; uint8_t TCCR1B_b = TCCR1B; uint8_t TCCR1A_b = TCCR1A; uint8_t TIMSK1_b = TIMSK1; // configure timer which starts the sampling noInterrupts(); // disable all interrupts TCCR1A = 0; TCCR1B = 0; TCNT1 = TimerPreloadValue; // preload timer //TCCR1B |= (1 << CS10)|(1 << CS12); // 1024 prescaler TCCR1B &= 248; // turns off timer? TIMSK1 |= (1 << TOIE1); // enable timer overflow interrupt ISR // demark sampling sample = NUMBER_OF_SAMPLES; // count down to zero digitalWrite(TRIGGER_START_SAMPLE_PERIOD_PIN,HIGH); samplingStart = micros(); TCNT1 = 65535; // first trigger right away! TCCR1B |= 1; // turns on timer interrupts(); // enable all interrupts // wait for sampling to be complete while(digitalRead(TRIGGER_START_SAMPLE_PERIOD_PIN)){}; samplingEnd = micros(); // restore timer registers TCNT1 = TCNT1_b; TCCR1B = TCCR1B_b; TCCR1A = TCCR1A_b; TIMSK1 = TIMSK1_b; }

I bought the Every because it implied it was backward compatible with the nano. No, it's not, as we found out. Be that as it may, any word on a getting the Every working with mySensors?

@eiten I haven't yet made any progress on finding a good VOC sensor, but along the way I did find out something interesting regarding CO2: namely, if you sleep with your bedroom door closed at night, then the odds are good that the CO2 levels rise to surprisingly high and unhealthy levels. The better CO2 sensors are factory calibrated and never again need recalibration for the life of the sensor (usually around 10 years or so), because they are used in HVAC systems to control fresh air intake to guarantee indoor air quality. As a for instance, here is one such CO2 sensor: https://www.digikey.com/en/products/detail/senseair/006-0-0008/15790694 At around $50 for just the sensor element itself, it's not exactly cheap, but then again, I'd say it's worth it, because who wants to be burdened by remembering to calibrate their CO2 sensors? Ideally, I'd like to find a sensitive VOC sensor that also will never require calibration. Nearly all, and maybe all, of the off-the-shelf IAQ montoring stuff that you might buy for, say, $300 or less seems to require periodic calibration. For that reason, this might be one of those occasions where build is rather than buy.