Hi All, Following along this thread for RS485, I'm having a difficult time getting any communication to be received from another RS485 Node. I've tried both the Master and Development Branchs on RPI A. In Compiling the configuration in either case, I see alot of Compiler Warning during the make process. Has there been any more movement regarding this repo since the last dated response in this thread. AS of June 6th 2017 - Like 5 Years AGO???

Success! In all my testing and trying new settings, I missed that I had commented out on the gateway the frequency setting. It was noobie mistake and I want to thank all of you for your help. I ended up using @FarmerEd's sketches to get my gateway and sensor to work. Thanks again.

To provide a large enough pulse to drive the ceramic transducer , you need a lot of energy, so they pump up the 5v with an inductor/transformer to provide a high voltage pulse. This is 60v or more… The more Energy you produce the farther the pulse will travel…. Everything thing else on the board run at 3.3 to 5V. Add a large Capacitor of 100 µF are so between the 5v and ground on the device, this may clean up your problem.. Some CPU modules just can’t supply enough current quick enough that’s needed when the pulse is triggered. These are very inexpensive device, we’re luck to see them work at 1/2 the spec range.

HI @Henil179 I made one myself a couple of years ago, and yes, it was a fair bit of trial and error to get it working. Of course, the gain values will be dependent on a number of factors, for example, the torque constant of your motor, the gear ratio, the mass of the robot, where your centre of gravity is located, your loop rate, and where you've located your mpu-6050. I located my mpu-6050 over the axis at 12 o'clock near the vertical centre of my bot. What are you control variables? I used pitch (angle of rotation around motor axis) calculated from gx, gz and tan function. I also used pitch rate from the gyro. Are you using the onboard DSP of the mpu-6050 to do the calculations? I had no luck with this, the mpu-6050 kept freezing up, bad clone I guess. You also have to verify the direction of rotation of your motor versus your control variables. If you have the wrong direction, it will just run away. My gains are Kp:41, Ki:160, Kd:0.4 I started with only Kp and kept increasing the value until the system became unstable, then I backed off to a stable point. Next, I began increasing Ki. This will bring you to steady state stability. It should balance itself when Kp & Ki. You will likely have to reduce Kp somewhat as you move to higher Ki values, if your system becomes unstable. Finally, I added Kd, to help it react more quickly to changes in angle. How do you change your gains? I have a bluetooth module on mine, to allow me to send serial commands to the robot, to set the gains and other things. My robot's biggest problem is gear backlash. This generates acceleration noise as it vibrates backward/forward, balancing itself. This vibration can feedback on itself and cause instability (when you increase Kp too high). It looks like the robot has Parkinsons when this happens! :grinning: I'd like to update my design to use a belt/gear drive or continuous rotation servo, but I haven't had a chance to get back to it. I hope this helps.

One Last (boring 😂 ) question... Have you placed a flyback diode across the inductor? I'm not sure if this component is strictly necessary.

I'm not really familiar with FHEM, but as far as the MySensors side, you still need the gateway software running. However, this code can run directly on a Raspberry Pi, at least with a radio network for the MySensors transport. I haven't ever used RS485 myself, but I would think it would be similar. At least the code itself has sections for dealing with running on Linux, which is what is used when running it on the RPi, so I think you're good. https://github.com/mysensors/MySensors/blob/master/hal/transport/RS485/MyTransportRS485.cpp The gateway code runs as a systemctl service, so it can easily run in parallel with most things, so probably wouldn't conflict with FHEM on the same device. Oh yeah, and in case you haven't found it, there's this page: https://www.mysensors.org/build/rs485

Hello everyone! Based on the quite useful reverse engineered schematic at https://hackaday.io/project/174308-tradfri-pir-motion-sensor-hacking the measurements were somewhat sabotaged by the 2N7002 (see Connors comment "enables voltage dividers only when triggered"). the transistor is controlled by the Elmos E931.96 PIR motion controller IC. The latter is programmable by the IKEA TRÅDFRI ICC-1 module's EFR32MG1P132F256GM32 MCU. E.g. 2. Blind Time Ignores motion after the interrupt output is switched back to 0 Range: 0.5s... 8s. The blind time is [Register Value] *0.5s 3. Programmable pulse counter 1... 4 pulses with sign change in between Amount of pulses = [Register Value] + 1 4. Window time For noisy environments 2s... 8s window Window time = [Register Value] * 2s + 2s https://github.com/basilfx/TRADFRI-Hacking gives a good overview on that. What is the issue with tose 60s?

@ejlane Correct. 7 nodes = 7 machines. BUT, the 7 current machines are 7 raspberry pi 4 (8gig Ram) modules. it is 1/2 of what my goal is. Eventually it will be a full 14 node cluster. I had been doing something similar with the pi satellites. I found that if you tell it to use a UDP broadcast to localhost for the wakeword/recording then it doesn't send the audio frames to the mqtt broker.

Main problem (already "quickfix" solved) is completely new and incompatibile interrupt system implemented in new (post-2016) ATtinys. More flexible, but also coming with some problems when using Arduino-like code and few libraries. Other than that, due to completely new power management these features I don't tested yet, may not work properly...

@Michiel-van-der-Wulp using a megaohms pull-up resistor solves the problem with current consumption, but now you have an input that is more susceptible to interference, because it is high impedance.

@martin3000 I just noticed that PTVO firmware does support the "serial bootloader": [image: 1637215954292-a5fd4e7f-0fb3-4df9-8a08-ec3aa55fa563-image.png] Anyway this feature is not documented too well.

@TriXwooD said in Double SPI Radio Raspberry Pi: dtparam=spi=on dtoverlay=spi1-1cs,cs0_pin=36 @TriXwooD : Thank you, this helped me a lot. I had to use a different pin number in /boot/cmdline.txt though for that it matches the pin number given in the configure statement: dtparam=spi=on dtoverlay=spi1-1cs,cs0_pin=16 ./configure --my-rf24-cs-pin=36 ... Configure wants the BCM pin number (36), but the dtoverlay wants the corresponding GPIO pin number (16).

Update Meanwhile I made progress with my project. Together with some colleagues I want to install a real-time measurement system with more than 30 channels (i.e. 30 Nano BLE 33 measuring accel. and gyro.) and one evaluation unit (another Nano BLE 33 combined with other computers). The 6 values (2*x,y,z) of 16 Bit each shall be transmitted with 10 measurements per second. Instead of spontaneous sending beacons with new measurement values from the 30 devices (to many collisions, real-time simply not possible) I use a master-slave polling, done by the evaluation unit. And I continue using non-connectable/non-scannable BLE-Beacons, for the request messages and for the response messages. Meanwhile, my beacons can be detected by typical BLE scanner APPs on my smartphone (Android 10). I do not know, why that did not work at the beginning. May be I corrected some mistakes incidentally in the last months. I am working also on a channel hopping (in case of disturbances by other devices with BT and WLAN) and using more channels for higher measurement speed. But the implementation of that will start later. 8 hours later Now I found a reason for the behavior of the Scan-APPs: My request beacons (without data, only user address of 6 bytes) are detected, but not the response beacons with data. I do not need the smartphones now (the speed of about 500 beacons per second is to fast for them), so I am happy with my solution.

@Jodaille Thanx for the link to the project. I think I'll order one of those sensors this weekend. As I hope it can also send the amount of rain that is falling. I do have to check the optical sensor. But I really like the heating in the controlli sensor

I can confirm the solution posted by FarmerEd works for me. I was able to transmit from a Lora32u4 ii (node) to a TTGO Lora32 gateway. As pointed in his post, the right line was: #define MY_RFM95_IRQ_NUM digitalPinToInterrupt(7) instead of #define MY_RFM95_IRQ_NUM MY_RFM95_IRQ_PIN or #define MY_RFM95_IRQ_NUM 7 Thanks very much again for taking the time to post the solution.

@raptorjr said in Glowing/pulsing yellow LED?: MKRNB 1500 It helps if you post a wiring diagram and a sketch.