@neverdie said in 2AAA battery NRF24 Sensor PCB with ATmega 328p:

Hmmm ... is that accurate? I thought digital LO may be higher than actual GND.

Yes, perfectly accurate. The output stage is a FET switch and the current it switches to GND is ~2 micro amps, It's 0V. One could measure the VCC an other way not needing a voltage divider by configuring the ADC so that it uses the VCC as the reference and then measure the internal 1.1V reference. However that takes re-configuring the ADC each time into and out of this mode if you need the ADC for other measurements as well and doesn't save any pins.

@neverdie
The LDO is only used when running from 5 or 12V supplies. Cant measure 3.3V with a 1.1V reference .

On this board I use a resistor voltage divider with the low end connected to a digital pin instead of ground. When a voltage reading is to be obtained the digital pin is commanded to become an output and set low, then wait for the filter capacitor to charge, take the reading and set the pin back to input. The same digital pin also has the push button switch connected which is checked elsewhere in the code, in that case the two resistors making up the voltage divider become the pull-up resistor for the switch . So the resistors and digital pin serve double duty. The internal reference of the 328p ( 1.1V ) is used as the reference for the ADC , which results in a very precise result.

Here is a MySensor node implementation on a PCB that can be ordered at OSHPARK.com. It contains a "Arduino pro - mini" chip( ATmega 328p) and has the footprint for a nrf24 radio built in as well as footprints for the necessary voltage regulators and capacitors if the node is to be run from 5V or 7-12V supplies. The Bat+/Bat- solder positions take either a 2 AAA or a 2 AA battery case. When used as a battery operated node, for example as a door/window sensor the batteries last about 2 years. The node has a built in way of measuring the battery voltage that doesn't itself deplete the battery slowly and features two LEDs driven from one digital pin.

The PCB's can be ordered at OSHPARK.com in the US , search in the shared project for "nrfMysensor. They cost around $9 per 3. Soldering is not too terribly hard. The smallest components are the two LEDs which can be left out. The arduino chip can be "harvested" from a pro/mini board, either the 8mhz/3.3V version for battery operation or the 16mhz/5V version for 5V-12V operation. Or load the appropriate bootloader onto a blank chip.

The EagleCAD board and schematic files can be found here :https://github.com/garyStofer/Eagle5_PCB/tree/master/nRF_Mysensor. The schematic contains notes on various build options.

Some example of using the boards in a battery scenario can be found here https://github.com/garyStofer/MyMySensors2.1 Wire_Trip_alarm and PIR_alarm_PCint

For battery powered nodes that need to completely sleep between events sleep(0) could be used in V1.5 in conjunction with the pin change interrupts on portC of an ATmega 328p. It would gracefully power down the radio and then enter the CPU into sleep mode until a pin change event on port C woke it up. In V2.1 sleep(0) simply returns. PortC pin-change mode is needed because INT0 and INT1 only work on either falling or raising level changes but not on either edge at the same time on the 328p .

I modified the file MyHwAVR.cpp as follows to restore the missing functionality back into V2.1 : Lines 150 and up:

int8_t hwSleep(unsigned long ms)
{


	if (ms>0) {
		// sleep for defined time
		hwInternalSleep(ms);
		return MY_WAKE_UP_BY_TIMER;
	} else {  // Fix for missing feature that allowed (in 1.5.1) to use the pin chnage interrupt with a sleep(0) to completely power down the system
		// sleep until ext interrupt triggered
		hwPowerDown(SLEEP_FOREVER);
		return 0;
	}


}

Let me know if this is the correct venue to bring this to the attention of the code maintainers, or if I should go and furnish a git pull request or something like that.

Or if this has been addressed in post V2.1.1 releases
Thanks
gary

I made a MySensor gateway node that works as a bridge to an existing X10 system. It allows to control the X10 light and appliance modules from the home automation software. The setup consists of a X10 remote which has been modified so that the digital signal from the gateway keys the transmitter. The X10 controller then receives the data package and does it's thing on the AC line to control the switches. Any existing X10 remote or alarm sensor can be used. I had an old key-fob with broken buttons that became the donor transmitter. When hacking the remote one looks for the signal from it's IC that normally keys the transmitter and disconnects that to feed the signal from the MySensor node instead. A scope is handy to find which pin is the right one.

The GIT with the Arduino script for the Gateway/X10 controller can be found at [https://github.com/garyStofer/MyMySensors2.1] . The X10 house code is hard-coded to 'A" and I limited the number of switches arbitrarily to 12, but the avid Arduino enthusiast will quickly see how to modify the code to suit. It is not necessary that the X10 part be implemented on the MySensor gateway, it could just as well be done on a separate node.

If there is any interest I will add some pictures and schematics.

@dbemowsk Initially I uses an AS5030 encoder, but then I switched to the EM-3242 as it's much cheaper and smaller and does the same. My board has an Op-amp inverter to change the sense of angle to voltage so that the magnet can run on the top of the chip rather than on the bottom. Only problem we had with the EM-3242 was that it has no hysteresis which shows up at the 360/0 junction.

I did some wind speed and direction sensor boards that I use in my own weather station design. All solid state and high resolution with analog signal readout, voltage for direction, 8 pulse per rev for speed. For inspiration see http://wws.us.to. Gary

@Yveaux So I found the problem now.

The disconnect between the sniffer and the network running V2.1 stemmed from the change in the way the NETWORK_BASE_ID is defined.

In the sniffer and V1.51 of the lib it is defined as a single uint64_t but in the V2.1 lib it is defined as a list of 5 individual bytes which are then later used to initialize a 5 byte char array via a macro.

Since earlier I had chosen a different NETWORK_BASE_ID from the default this uint64_t defined ID was now used to initialize the 5 byte array, except of course that only the first location got assigned anything. Luckily all of this happened without a compiler warning or error...

After I changed the NETWORK_BASE_ID in my nodes & gateway to use the 5 individual bytes format in the correct order everybody is all again. Even my V1.51 sensors that have not been recompiled yet seem to be just fine with the network.

Thanks

And I forgot to mention that the data rate in the sniffer and the network match as well..