@lis610 I have found with a 499K resistor the range is reduced to about 1.2m in a ABS box.
With a 1Mohm it was about 3m, I do not have many high value SMD resistors to experiment with but the lower the value the lower the range.
Just tried with a 333K and it operates about 0.8m in free air.
@scurb This looks very interesting and my factor now to save me from having to create my own :-). I have been planning to do the same thing (although maybe on a smaller software scale) by writing a simple Python server that would pull serial packets off of a gateway arduino (either running mysensors or something I write myself) and pipe this through MQTT to openHAB. I have two questions:
How do you interface with a sensor network? Do you go through a serial connection to read the serial packet format (a,b,c,d)? I see several implementations that put the mqtt client directly on the Arduino, but it seems much cheaper for me to just plug it into a USB port to get a virtual serial port instead of investing in a separate ethernet shield
How does an item configurations look like for a switch in openHAB? I'm looking to build a toggle switch which toggles light on or off every time it is activated, and I cannot really understand how to configure the switch to allow this behaviour for an mqtt input.
Feel free to take the second question with me directly since this might not be very interesting to the others in the forum
In general, yes, the MySensors framework (library?) should support FOTA a couple different ways (read more at link). Were you aware of this, or is there some problem with your particular hardware?
@NielBierman said in FOTA possibilities for remote sensor network:
Raspberry pi
I don't know yet whether you even need to change your gateway from microcontroller (uC) to Single Board Computer (SBC) or not. However if you do (or are looking for a controller, or whatever), by all means, please do yourself (and all of us) a favor and do a little more research as there are lots of better options out there for SBC nowadays, than RPi!
For me, uC have been fine for gateway although I do use some SBC for controllers, MQTT broker, and various other GNU/Linux based servers/services and they are wonderful for that. But perhaps your needs are different from mine.
@dzungpham0703
I replied in the nrf51822 thread. Yes I managed to make it work like the original with BLE stack. And using the wonderful Cypress Proc BLE solution including capsense and lots of goodies . Cypress really rocks! I love them.
The current consumption was lowered to 200uA without being connected and 700uA connected. Those numbers include LEDs current consumption and other blocks like touch sensing.
I'll get back with more updates when it's finished.
Very useful topic for me, thanks. Even though it's been a long time, the information was useful to me. And especially the information on the link you sent.
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.
@yveaux said in Ikea Molgan Hack:
@magpern the instructions on openhardware.io state that the Molgan must be battery powered while programming:
Well, then I can confirm that you don't have to power the Molgan from batteries just for programming. Burning the bootloader works fine with just power from the ISP port and programming it through FTDI works fine if power comes from the FTDI.
What I found wierd is that the atmega328 had power, the radio had power, it wrote debug messages to the FTDI - when powered through the FTDI, it send radio messages etc, but it just did not receive messages.
Messages where not received until I supplied power to the + / - pads (battery pads).
I did read the instructions on openhardware.io, but I didn't follow then to the t.
