@toyman
Unfortunately, yes, I have returned the jumpers to their original settings, and have even tried all 4 combinations.
I also changed computers, changed OS's, changed cables.
The board LOOKS like it was well manufactured, but I suppose a bad board is a possibility. Other than that, I can't figure out what could be wrong.
I got to the point where the stm32loader.py runs and outputs:
Bootloader version 22
Chip id: 0x410 (STM32 Medium-density)
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
[..snip..]
Write 256 bytes at 0x8001900
Write 256 bytes at 0x8001A00
Read 256 bytes at 0x8000000
Read 256 bytes at 0x8000100
[..snip..]
Read 256 bytes at 0x8001900
Read 256 bytes at 0x8001A00
Verification OK
After that, you're supposed to plug in to the USB directly. I get " USB device not recognized". Zadig doesn't help. It lists it as:
"Unknown USB Device (Device Descriptor Request Failed)"
Any ideas?
Thanks.
@tmaster
Actually, the KY-038 works exactly what I want (except for the power consumption). I also have ones that are connect to mains power, and the false alarms are rare. Also, I have the Arduino programmed to sleep some time after detecting a sound and sending a message. In the case of a real alarm, it will keep sending regularly, which would make it obvious. The "batteries just end in a few months" is what I'm asking about - avoiding the .4ma used by the LM393. I'm hoping I can replace it with the LMV393, but I'm not sure if it will work.
Regarding the "you think you are safe", Mysensors has heartbeats, and battery percentage reporting to deal with all that.
@tmaster
I appreciate the reply, but I really do not want to open up or modify the smoke alarm in any way - just detect a loud sound. As I said, I really just want a KY-038 that is suitable for battery operation.
That scheme is interesting, but I don't want to actually fiddle with the detector - for fear I will cause a malfunction. Hence my request of "without using power from the detector itself." Also, it would be nice to detect any kind of alarm (loud noise), not just a smoke detector.
@ileneken3
I want to detect when a smoke detector is sounding an alarm without using AC power, and without using power from the detector itself. I currently detect an alarm (really, any loud sound) using the standard KY-038 module, like this:
But this can't be used for a battery application because the KY-038 has a LM393 on it, which draws .4 ma.
I ordered a LMV393, which is more suitable for battery operations, to replace it. But I'm not sure if that would work, or if I could manage the SMD soldering without breaking the board.
I played with a microphone like this:
https://www.adafruit.com/product/1063
but I can't get it to trigger the interrupt correctly while the Arduino is sleeping. (Maybe an extra capacitor?).
Any ideas?
Thanks!
@mr_red
I can add some of my own "documentation" on this issue. I only recently was able to program an Ebyte E73 module, and it was a long struggle. I used the NRF DK, and had help from a Nordic engineer.
Using the P20 and P1 headers, connect:
P20 VDD -> 3.3v on EBYTE 2G4M04S1B module
P20 SWDIO -> SWDIO on EBYTE 2G4M04S1B module
P20 SWDCLK -> SWDCLK on EBYTE 2G4M04S1B module
P20 VTG -> P1 VDD
P1 GND -> GND on EBYTE 2G4M04S1B module
To unlock the chip, execute:
nrfjprog -f nrf52 --recover
They also recommend using nrfjprog to program the device, because nRFgo Studio is deprecated. But I used the Studio and it worked fine. I gave Studio the .hex produced by the Arduino IDE using "Sketch" -> "Export compiled Binary".
As mentioned in the previous post, it is unlikely to unlock the board with anything but the NRF DK or a genuine J-Link. (Maybe a good fake J-Link).
Mistakes others may be able to learn from:
Yes, I understood what you meant. I will only do the "Export compiled Binary" from the IDE, and leave the drivers as J-Link commander or nrfGo Studio wants them.
In: https://www.openhardware.io/view/376/MySensors-NRF5-Platform it says:
"Currently, the nRF52832 and nRF51822 are supported so we recommend sticking with those for now."
I noticed that my board: (E73-2G4M04S) is labeled "NRF52810". So is that why after programming it nothing works (nothing seen on gateway) 
?
If so, I messed up on that order.
But I am also trying the E73 2G4M04S1B, which at least from the AliExpress order
https://www.aliexpress.com/item/CDEBYTE-E73-2G4M04S-BLE-4-2-5-0-long-distance-100m-2-4GHz-SMD-ARM-Core/32820692238.html?spm=a2g0s.9042311.0.0.27424c4dSKBLn7
says it is nRF52832. (It isn't labeled on the board though). For this module, I can't unlock it using "Recover" from nRfgoStudio. It always fails with a message "Recover failed: Unknown error".
From the command line, if I do
nrfjprog.exe -f NRF52 --recover --log
and it comes back immediately with:
Recovering device. This operation might take 30s.
ERROR: Recover failed. Please make sure that the correct device family is given
ERROR: and try again.
The key error from the log seems to be:
2018-Dec-27 12:25:22 . . . . . nRF52_power_debug_and_system_regions
2018-Dec-27 12:25:22 . . . . . . nRF52_write_debug_port_register
2018-Dec-27 12:25:22 . . . . . . nRF52_write_debug_port_register: JLink: JLINK_CORESIGHT_WriteAPDPReg(DP reg 0x02, 0x00000000)
2018-Dec-27 12:25:22 . . . . . . nRF52_write_debug_port_register: JLink: returns -1
2018-Dec-27 12:25:23 . . . . . . nRF52_write_debug_port_register: JLink: (0005ms, 0288ms total)
2018-Dec-27 12:25:23 . . . . . . nRF52_write_debug_port_register: JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.
2018-Dec-27 12:25:23 . . . . . nRF52_power_debug_and_system_regions: JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.
If I do: nrfjprog.exe -f NRF51 --recover --log
it actually makes LD5 on the DK board flash for 30 seconds, but still returns failure with the exact same message.
Any other tricks for "recover/unlock" of those boards?
Thanks!
@neverdie
Unfortunately, nothing is that simple - at least for me. I have gone in circles with the J-LINK drivers. In order to use the Arduino IDE for programming, you must use the WinUSB driver installed by Zadig. But if you do that, the nRFgo Studio no longer recognizes any J-LINK device. So I re-install RFgo Studio, and then I can't use the Arduino IDE anymore!
But I can work around those issues, because everything programs and works right when programming the device on the NRF DK board. The problem is I can't do anything with the two external boards I tried. With one, I was able to unlock it with a "Recover" in nRFgo Studio, but the programming doesn't seem to cause the chip to do anything (nothing logged by the gateway). With the other, I can't unlock the board - it always says: "Recover failed: Unknown error".
Both boards are E73 - but one is marked as E73-2G4M04S and the other is E73-2G4M04S1B.
Any ideas?
@omemanti
I was looking at the output of mysgw running on a Raspberry PI - so Domoticz is not really in the picture. But - your advise made me think I should try programming the chip on the development board directly before using an external one. And it works! I can see the registration of the Mysensors device.
So I guess everything is OK in terms of IDE and Mysensors code, and there must be something wrong with my external board. I will have to try a different one, and/or look over the soldering.
Happy Holidays!
@ileneken3
OK, I fixed one layer of the problem! I removed the JLINK driver using Device Manager, then re-installed using Zadig. Now the Arduino IDE tells me it is programmed without a problem.
But the next layer of the problem still exists, the programmed board doesn't seem to send anything to the gateway. I am monitoring this from the logs of mysgw, and from Domoticz. I am expecting the gateway to see something from the node, at least the registration.
Thanks again
C:\Users\krakman\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/jlink.cfg -c transport select swd; set WORKAREASIZE 0; -f target/nrf52.cfg -c program {{C:\Users\krakman\AppData\Local\Temp\arduino_build_268238/MyBoardNRF5tst.ino.hex}} verify reset; shutdown;
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
jaylink: Failed to open device: LIBUSB_ERROR_NOT_FOUND.
Info : No device selected, using first device.
Error: No J-Link device found.
Error: No Valid JTAG Interface Configured.
Error: No Valid JTAG Interface Configured.
/*
If you don't use an nRF5 board, you can ignore this file.
This file was part of the "My Sensors nRF5 Boards" board repository
available at https://github.com/mysensors/ArduinoBoards If you have
questions, please refer the documentation at
https://github.com/mysensors/ArduinoHwNRF5 first.
This file is compatible with ArduinoHwNRF5 >= 0.2.0
This file allows you to change the relation between pins referenced in
the Arduino IDE (0..31) and pins of the nRF5 MCU (P0.00..P0.31).
If you can live with addressing the GPIO pins by using the Arduino pins
0..31 instead of a custom mapping, don't change this file. If you have
a lot of Arduino code with fixed pin numbers and you need to map these
pins to specific pins of the nRF5 MCU; you need to change this file.
If you fill the "g_APinDescription" Array with numbers between 0..31,
the Arduino pins 0..31 are assigned to pins P0.00..P0.31 of the MCU.
As an example, if you need to change the pin mapping for Arduino pin 5
to P0.12 of the MCU, you have to write the 12 after PORT0 into the sixth
position in the "g_APinDescription" Array.
The extended attributes only affects the nRF5 variants provided with
official Arduino boards. The arduino-nrf5 variant ignores the extended
attributes.
The pin mapping effects commands like "pinMode()", "digitalWrite()",
"analogRead()" and "analogWrite()".
If you change the pin mapping, you have to modify the pins in
"MyBoardNRF5.h". Especially the analog pin mapping must be replaced with
your pin numbers by replacing PIN_AIN0..7 with a number of your mapping
array. You can use the constants PIN_AIN0..7 in the "g_APinDescription"
Array if you want to reference analog ports MCU independent. You cannot
use the pins P0.00 and P0.01 for GPIO, when the 32kHz crystal is connected.
###########################################################################
Copyright (c) 2014-2015 Arduino LLC. All right reserved.
Copyright (c) 2016 Arduino Srl. All right reserved.
Copyright (c) 2017 Sensnology AB. All right reserved.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifdef MYBOARDNRF5
#include <variant.h>
/*
* Pins descriptions. Attributes are ignored by arduino-nrf5 variant.
* Definition taken from Arduino Primo Core with ordered ports
*/
const PinDescription g_APinDescription[]=
{
{ NOT_A_PORT, 0, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // LFCLK
{ NOT_A_PORT, 1, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // LFCLK
{ PORT0, 2, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A0, PWM4, NOT_ON_TIMER},
{ PORT0, 3, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A1, PWM5, NOT_ON_TIMER},
{ PORT0, 4, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A2, PWM6, NOT_ON_TIMER},
{ PORT0, 5, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A3, PWM7, NOT_ON_TIMER},
{ PORT0, 6, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT3
{ PORT0, 7, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT4
{ PORT0, 8, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM10, NOT_ON_TIMER}, //USER_LED
{ PORT0, 9, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // NFC1
{ PORT0, 10, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // NFC2
{ PORT0, 11, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // TX
{ PORT0, 12, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // RX
{ PORT0, 13, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SDA
{ PORT0, 14, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SCL
{ PORT0, 15, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SDA1
{ PORT0, 16, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SCL1
{ PORT0, 17, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // TP4
{ PORT0, 18, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // TP5
{ PORT0, 19, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT2
{ PORT0, 20, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT1
{ PORT0, 21, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT1
{ PORT0, 22, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM9, NOT_ON_TIMER},
{ PORT0, 23, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM8, NOT_ON_TIMER},
{ PORT0, 24, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT
{ PORT0, 25, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM11, NOT_ON_TIMER}, //RED_LED
{ PORT0, 26, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM11, NOT_ON_TIMER}, //GREEN_LED
{ PORT0, 27, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM11, NOT_ON_TIMER}, //BLUE_LED
{ PORT0, 28, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A4, PWM3, NOT_ON_TIMER},
{ PORT0, 29, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A5, PWM2, NOT_ON_TIMER},
{ PORT0, 30, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A6, PWM1, NOT_ON_TIMER},
{ PORT0, 31, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A7, PWM0, NOT_ON_TIMER}
};
// Don't remove this line
#include <compat_pin_mapping.h>
#endif
/*
If you don't use an nRF5 board, you can ignore this file.
This file was part of the "My Sensors nRF5 Boards" board repository
available at https://github.com/mysensors/ArduinoBoards If you have
questions, please refer the documentation at
https://github.com/mysensors/ArduinoHwNRF5 first.
This file is compatible with ArduinoHwNRF5 >= 0.2.0
This file allows you to change the pins of internal hardware, like the
serial port, SPI bus or Wire bus.
All pins referenced here are mapped via the "g_ADigitalPinMap" Array
defined in "MyBoardNRF5.cpp" to pins of the MCU.
As an example, if you have at the third position in "g_ADigitalPinMap" the
12, then all ports referenced in Arduino with 2 are mapped to P0.12. If you
don't change the "g_ADigitalPinMap" Array, the Arduino pins 0..31 are
translated to P0.00..P0..31.
###########################################################################
This file is compatible with ArduinoHwNRF5 > 0.1.0
Copyright (c) 2014-2015 Arduino LLC. All right reserved.
Copyright (c) 2016 Sandeep Mistry. All right reserved.
Copyright (c) 2017 Sensnology AB. All right reserved.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef _MYBOARDNRF5_H_
#define _MYBOARDNRF5_H_
#ifdef __cplusplus
extern "C"
{
#endif // __cplusplus
// Number of pins defined in PinDescription array
#define PINS_COUNT (32u)
#define NUM_DIGITAL_PINS (32u)
#define NUM_ANALOG_INPUTS (8u)
#define NUM_ANALOG_OUTPUTS (8u)
/*
* LEDs
*
* This is optional
*
* With My Sensors, you can use
* hwPinMode() instead of pinMode()
* hwPinMode() allows to use advanced modes like OUTPUT_H0H1 to drive LEDs.
* https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/nrf5_wiring_constants.h
*
*/
#define PIN_LED1 (8)
// #define PIN_LED2 (25)
// #define PIN_LED3 (26)
// #define PIN_LED4 (27)
// #define PIN_LED5 (12)
// #define PIN_LED6 (14)
// #define PIN_LED7 (15)
// #define PIN_LED8 (16)
// #define USER_LED (PIN_LED2)
// #define RED_LED (PIN_LED3)
// #define GREEN_LED (PIN_LED4)
// #define BLUE_LED (PIN_LED1)
// #define BLE_LED BLUE_LED
#define LED_BUILTIN PIN_LED1
/*
* Buttons
*
* This is optional
*/
// #define PIN_BUTTON1 (3)
// #define PIN_BUTTON2 (4)
// #define PIN_BUTTON3 (5)
// #define PIN_BUTTON4 (6)
// #define PIN_BUTTON5 (7)
// #define PIN_BUTTON6 (8)
// #define PIN_BUTTON7 (9)
// #define PIN_BUTTON8 (10)
/*
* Analog ports
*
* If you change g_APinDescription, replace PIN_AIN0 with
* port numbers mapped by the g_APinDescription Array.
* You can add PIN_AIN0 to the g_APinDescription Array if
* you want provide analog ports MCU independed, you can add
* PIN_AIN0..PIN_AIN7 to your custom g_APinDescription Array
* defined in MyBoardNRF5.cpp
*/
static const uint8_t A0 = ADC_A0;
static const uint8_t A1 = ADC_A1;
static const uint8_t A2 = ADC_A2;
static const uint8_t A3 = ADC_A3;
static const uint8_t A4 = ADC_A4;
static const uint8_t A5 = ADC_A5;
static const uint8_t A6 = ADC_A6;
static const uint8_t A7 = ADC_A7;
/*
* Serial interfaces
*
* RX and TX are required.
* If you have no serial port, use unused pins
* CTS and RTS are optional.
*/
/*
#define PIN_SERIAL_RX (12)
#define PIN_SERIAL_TX (11)
*/
// I changed this....
#define PIN_SERIAL_RX (13)
#define PIN_SERIAL_TX (14)
// #define PIN_SERIAL_CTS (13)
// #define PIN_SERIAL_RTS (14)
/*
* SPI Interfaces
*
* This is optional
*
* If SPI is defined MISO, MOSI, SCK are required
* SS is optional and can be used in your sketch.
*/
#define SPI_INTERFACES_COUNT 1
#define PIN_SPI_MISO (2)
#define PIN_SPI_MOSI (3)
#define PIN_SPI_SCK (4)
#define PIN_SPI_SS (5)
static const uint8_t SS = PIN_SPI_SS;
static const uint8_t MOSI = PIN_SPI_MOSI;
static const uint8_t MISO = PIN_SPI_MISO;
static const uint8_t SCK = PIN_SPI_SCK;
/*
* Wire Interfaces
*
* This is optional
*/
#define WIRE_INTERFACES_COUNT 2
#define PIN_WIRE_SDA (13u)
#define PIN_WIRE_SCL (14u)
#define PIN_WIRE_SDA1 (15u)
#define PIN_WIRE_SCL1 (16u)
static const uint8_t SDA = PIN_WIRE_SDA;
static const uint8_t SCL = PIN_WIRE_SCL;
#ifdef __cplusplus
}
#endif
#endif
@ileneken3
After giving up on the cheap (illegal?) ST-LINK and J-LINK boards, I decided to make my life easy and get a NRF-DK. Unfortunately, even that is not easy enough . I did manage to use nRFgo Studio to flash a pre-built .hex file (blinky_pca10040.hex) to the EBYTE E73 module. I know it works because I attached an LED to a pin on the module and I see it blinks. But I can't do what I really want - flash a simple Mysensors sketch (preferably with the Arduino IDE).
Everything compiles OK, I'm using the very latest MyBoardNRF5 board definition (including the Sandeep Mistry libraries). But the Arduino IDE won't recognize the J-LINK programmer that is built into the DK board. (Maybe that's not expected to work?)
As a workaround, from the Arduino IDE, I select "Export compiled Binary", and then use the resultant .hex file with nRFgo Studio to flash the board. Everything seems fine, but I get no indication from the gateway that any wireless traffic is received from the board - so I assume it is not working at all. Below is the sketch.
#define MY_RADIO_NRF5_ESB
#define MY_DEBUG
#define MY_NODE_ID 10 // 0x0a nrf test
#define CHILD_ID 55 // Id of the sensor child
#include <SPI.h>
#include <MySensors.h>
// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);
bool value = 1;
void setup() {
Serial.println("I am starting");
send(msg.set(value)); // Get things started
// initialize digital pin LED_BUILTIN as an output.
//pinMode(13, OUTPUT);
}
void presentation() {
sendSketchInfo("NRF52", "0.9");
present(CHILD_ID, S_MOTION);
}
void loop() {
Serial.println("I am in a loop");
//digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
//delay(3000); // wait for a second
//digitalWrite(LED_BUILTIN, LOW);
delay(3000); // wait for a second
}
P.S.
I have not managed to get any console output using the TX/RX pins to work either.
It would really brighten up my holidays if someone could point me in the right direction!
Thanks,
Yes, I'm connecting 3.3 volts to VCC and GND on the board, while connecting the programmer to the PC's USB port. I'm assuming there is no need for a common ground?
Oh well...
Yes, I used Zadig. From the Device Manager in Windows, it displays "STM32 STLink" when the programmer is plugged in.
In Linux, the device seems to be recognized automatically without installing any drivers.
Unfortunately- I did try that - although without an led it’s hard to know if the board really is getting power. I will check with a multimeter.
I have tried EVERYTHING to get an ST-LINK V2 to program an NRF52. That includes - multiple ST-LINK's, multiple computers, Linux, "burn bootloader" first, and pretty much everything I could read on this forum. The error message is always:
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v32 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.252590
An error occurred while uploading the sketch
Error: init mode failed (unable to connect to the target)
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked
Any ideas?
Thanks!
@crankycoder
What I meant was that keep the sensor as is (whether it is a pro mini or anything else), and use a different pro mini as the watchdog - in place of the TPL5010. In this case, it would take a double board failure in order to have a complete failure.
Speaking of pricing, a Pro Mini 3.3Mhz can be had for as little as $2-$3. Couldn't that be used to provide all the functionality (and more) of a TPL5010? Of course, it would require a small programming with a small script that uses low power sleep, removing the LED, maybe regulator too.
I use an accelerometer ( search for MMA8452Q in AliExpress), along with code that checks the orientation:
byte pl = accel.readPL();
switch (pl)
{
case PORTRAIT_U:
Serial.println("Portrait Up");
break;
case PORTRAIT_D:
Serial.println("Portrait Down");
break;
case LANDSCAPE_R:
Serial.println("Landscape Right");
break;
case LANDSCAPE_L:
Serial.println("Landscape Left");
break;
case LOCKOUT:
Serial.println("Flat");
break;
}
if ( pl == LOCKOUT ) { // flat
garage_state = GARAGE_CLOSED;
} else {
garage_state = GARAGE_OPEN;
}
Those CDEbyte modules work great for me too. So it becomes:
Or, scrap it all, and use an NRF5 module for everything. I'm still hesitant to jump in - but that may be the future of mysensors. There is a huge forum on that.
One advantage to the "atmega328p+nRF24L01 combo" is the simplicity of choices. A pro-mini is pretty much a pro-mini, etc. Having so many choices makes it hard for a beginner with nrf51.
I really appreciate the recommendation for a reasonably priced nrf51 that can be used for battery powered nodes. Can I also ask for a recommendation on a piece of hardware to program it? (Again, lots of choices).
Thanks ahead of time.
Congratulations on winning the contest. That convinces me to give it a try.
Even though this has been available for months, I'm not seeing much discussion on:
Anyone have feedback on those yet?
Thanks ahead of time
According to the new documentation, my build is now officially approved by you! Of course, it would be interesting to hear what the exact effect of jumping both jumpers is. All I know is that it works. There seem to be a lot of sensors that work fine down to 1.9V, so I would think that this configuration would be useful. (Assuming that reprogramming the bootloader is not too hard - I didn't think so).
So did you consider making the LIPO configuration "official"? So far, it seems that it works fine for me. It is good for when you really want a small footprint and/or your sensor needs 3.3V. Unfortunately, not as long a life as 2 AA, but you don't have to deal with the booster's expense and possible radio interference.
@dbemowsk
Yes, I appreciate the help! I am hoping others are learning from my adventures. It wouldn't be a fun hobby without a bit of frustration here and there 
I am attaching fresh pictures. The sensor attached is a "fork" for plant moisture monitoring.
"100 different combinations"
Yes, I meant the spreadsheet to be a list of typical examples - not a comprehensive list. For a "newbie", having a cookbook style recipe is useful.
I have never used RAW.
Regarding:
What kind of hardware and power supply did you use? Did you use a tested radio (to exclude radio failure).
I used 2 AA , a 3.3V pro mini with no BOD. I tested the radios, and even tried different ones. I can send a picture - but there's nothing interesting with it. So, the existing mystery is: why do I need to short both BAT and REG (which I know now is illegal)? I tried all combinations of shorting/not shorting jumpers - that is the only one that worked.
OK, I started over again with the moisture sensor -taking all the advice I got.
I turned it all on , and got the same !TSM:INIT failures. Just when I was about to throw the board against the wall, I took a shot at shorting the REG (in addition to the BAT). Then everything worked great!
I guess I don't understand why that worked. I figured I'd write myself a spreadsheet, and fill in the combinations. Attached is my start.
Comments/Corrections?
I am enclosing a picture of my attempt at a "workaround". Someone might get a good laugh out of it!
This was a bit of a challenge to do - and it STILL doesn't work. I measure continuity with all the right pins, but I probably damaged the board. This should have been the first thing I did.
In answer to all the questions:
I appreciate the help. Hopefully others have learned from my experience! I will report any other interesting findings.
Hello everyone:
I took Gohan's advice and did the continuity tests. On two of the boards I tested, there was a lack of connectivity to pins 10 and 11. (Pins 9,13, and 12 were fine).
These boards were from two different batches.
Below is a picture of a board that was actually working for weeks. Then I get the same !TSM:INIT:TSP FAIL failures rolling out. Since this was a plant moisture sensor, I assumed it was because I got some water on it - but maybe not.
On one of the boards, I de-soldered the radio. Then the continuity was even worse. I don't even want to show a picture of it
So - does this provide more clues? Any idea on the best way to salvage parts now? I have a feeling the pro-mini is just fine.
Thanks again!
Re: Easy/Newbie PCB for MySensors
Over the course of months using the boards, I'm up to 4 boards that I have had to "put aside" due to hardware problems. Maybe the radio is bad, maybe the pro-mini, maybe the board itself. I have been waiting for a day when I would try to recover what I could. My last failure was the most aggravating - I tested the radio, tested the pro-mini - everything was OK. Then I soldered them onto the newbie board, and I get the rolling:
0 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0-beta
49 TSM:INIT
65 TSF:WUR:MS=0
81 !TSM:INIT:TSP FAIL
114 TSM:FAIL:CNT=1
131 TSM:FAIL:DIS
147 TSF:TDI:TSL
10174 TSM:FAIL:RE-INIT
10190 TSM:INIT
10223 !TSM:INIT:TSP FAIL
10256 TSM:FAIL:CNT=2
I assume a connection to the radio is bad. It would be better if I always used female headers so I could swap out boards - but it makes the package so much bigger - I don't like them.
I'm looking for tips for avoiding problems, and how to recover boards.
Should I try to de-solder the pro-mini first? The radio?
Is it possible my soldering iron is too hot?
Should I test the newbie board before using it?
Are there any tips for diagnosing connection problems on the board, or identifying what is bad?
Thanks ahead of time!
Consider this option:
Use 2 AA batteries.
Change the BOD on the arduino to something lower than the 2.8V default.
Power everything from the batteries except the sensor.
Use the 5V step-up converter only for the sensor.
@gohan
I tried. Unfortunately, it didn't seem to matter with either or both those changes
I did try many combinations of sleep,wait,delay. I always get at least 2 messages sent.
Below, I posted the code and the debug log.
Thanks again.
Tried all suggestions. Here is the whole code:
/**
The MySensors dev version
**/
#define MY_NODE_ID 89
#define MY_PARENT_NODE_ID 88 // Main floor repeater
#define CHILD_ID 88 // Id of the sensor child
#define MY_RF24_PA_LEVEL RF24_PA_HIGH // Attempt to get radio to work
#define MY_BAUD_RATE 9600
#define MY_RADIO_NRF24
#define MY_DEBUG // Enables debug messages
#include <MySensors.h>
unsigned long SLEEP_TIME = 360000; // 6 minutes between heartbeats
#define DIGITAL_INPUT_SENSOR 3 // The digital input attached to vibration sensor.
// Initialize message
MyMessage msg(CHILD_ID, V_TRIPPED);
void setup()
{
Serial.begin(9600); // 9600 needed for 1MHZ
pinMode(DIGITAL_INPUT_SENSOR, INPUT); // sets the motion sensor digital pin as input
pinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);
wait(100);
Serial.println("Sending a message with value = 1 to get things started");
send(msg.set(1));
}
void presentation() {
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Mailbox Sensor 1Mhz", "1.5");
// Register all sensors to gw (they will be created as child devices)
present(CHILD_ID, S_MOTION);
}
void loop()
{
// Sleep until woken by sensor, or timeout
// Tried with FALLING and RISING also.
switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
{
case MY_WAKE_UP_BY_TIMER:
Serial.println("Woke up after SLEEP_TIME seconds so sending heartbeat");
sendHeartbeat();
break;
case MY_SLEEP_NOT_POSSIBLE:
Serial.println("Unable to sleep ;-(");
break;
default:
Serial.println("Sending a message with value = 1 !!!!!!");
// Tried with sleep(15), sleep(1000), sleep(10000). delay(1000) and wait(4000)
wait(4000);
#ifdef SHOULD_NOT_BE_NEEDED
while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
Serial.println("Clearing interrupts");
}
#endif
break;
}
}
Here is the debug log:
0 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0-beta
49 TSM:INIT
65 TSF:WUR:MS=0
81 TSM:INIT:TSP OK
114 TSM:INIT:STATID=89
131 TSF:SID:OK,ID=89
163 TSM:FPAR
212 TSF:MSG:SEND,89-89-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
737 TSF:MSG:READ,0-0-89,s=255,c=3,t=8,pt=1,l=1,sg=0:0
786 TSF:MSG:FPAR OK,ID=0,D=1
1179 TSF:MSG:READ,88-88-89,s=255,c=3,t=8,pt=1,l=1,sg=0:1
1245 TSF:MSG:FPAR PREF
1261 TSF:MSG:FPAR OK,ID=88,D=2
1294 TSM:FPAR:OK
1327 TSM:ID
1343 TSM:ID:OK
1359 TSM:UPL
1376 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
3473 TSM:UPL
3489 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
3571 TSF:MSG:READ,0-88-89,s=255,c=3,t=25,pt=1,l=1,sg=0:2
3637 TSF:MSG:PONG RECV,HP=2
3670 TSM:UPL:OK
3686 TSM:READY:ID=89,PAR=88,DIS=2
3735 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
3817 TSF:MSG:READ,0-88-89,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
3899 TSF:MSG:SEND,89-89-88-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.2.0-beta
3997 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:88
6111 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=11,pt=0,l=19,sg=0,ft=0,st=OK:Mailbox Sensor 1Mhz
6225 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.5
6324 TSF:MSG:SEND,89-89-88-0,s=88,c=0,t=1,pt=0,l=0,sg=0,ft=0,st=OK:
6406 MCO:REG:REQ
6422 TSF:MSG:SEND,89-89-88-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
6504 TSF:MSG:READ,0-88-89,s=255,c=3,t=27,pt=1,l=1,sg=0:1
6586 MCO:PIM:NODE REG=1
6602 MCO:BGN:STP
Sending a message with value = 1 to get things started
6766 TSF:MSG:SEND,89-89-88-0,s=88,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=OK:1
6881 MCO:BGN:INIT OK,TSP=1
6897 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
6963 TSF:TDI:TSL
6995 MCO:SLP:WUP=1
7012 TSF:TRI:TSB
Sending a message with value = 1 !!!!!!
11059 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
11108 TSF:TDI:TSL
11141 MCO:SLP:WUP=1
11157 TSF:TRI:TSB
Sending a message with value = 1 !!!!!!
15204 MCO:SLP:MS=360000,SMS=0,I1=1,M1=1,I2=255,M2=255
15253 TSF:TDI:TSL
I always get at least two messages, sometimes more.
Here is the sensor:
The new version didn't seem to help with my scenario - a vibration sensor where I only want to send one message per "event". (A vibration detected within a few seconds, or more). Using the default handling:
switch ( sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME) )
{
case MY_WAKE_UP_BY_TIMER:
sendHeartbeat();
break;
case MY_SLEEP_NOT_POSSIBLE:
Serial.println("Unable to sleep ;-(");
break;
default:
Serial.println("Sending a message with value = 1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!");
send(msg.set(1));
}
There are always 2 messages sent. This happens even if I add a sleep either before or after the send().
My workaround has been to add this after the send():
while (sleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, 2000) != MY_WAKE_UP_BY_TIMER ) {
Serial.println("Clearing interrupts");
}
I'm not sure the workaround is a good idea - because it may cause other problems. Any other ideas? Or is this correct?
Thanks!
This worked well for me, for a vibration sensor:
if (sleep(digitalPinToInterrupt(MOTION_INPUT_PIN), CHANGE, SLEEP_TIME) != -1) {
// Interrupt occurred, do whatever is needed and then
// clear any "floating" interrupts before going on.
while (sleep(digitalPinToInterrupt(MOTION_INPUT_PIN),CHANGE,1000) != -1 ) {
Serial.println("Clearing interrupts");
}
}
@Samuel235
The key question here (at least for this forum subject), is "should you a LIPO with a Easy/Newbie PCB board"? My answer is "in some cases". For sure, the gold standard of sleeping nodes is 2 AA batteries that last over a year. It's best both in terms of price and longevity. But there are scenarios for using LIPO's:
The AA batteries are too big. LIPO's come in all sizes, and the one from my old cell phone was nice and compact for a particular enclosure I wanted to use.
You have LIPO's lying around (like from an old laptop) and you just want to use them.
The sensors you are using are "power hungry" and you just can't find a way around it (and you can't plug it into the wall). Using a LIPO will avoid having to throw away a lot of AA's.
As far as discharge rate, from what I read it's not too bad (just not as good as AA's). With sensors that are not power hungry, and with the right voltage regulator (like a MCP1700), I am anticipating it lasting for months. At that point, it's not that big of a deal to recharge with that frequency.
For use with power hungry sensors (which may mean using just 2 ma), I am hoping for weeks.
I will continue with the experiment unless someone says I am way off in my estimations.
OK, looks like I had multiple problems.
I somehow missed the instructions about "don't solder both", and was also slightly confused about the directions because I am using a battery (LIPO), but following the "5V regulated" instructions. When the instructions mention battery, it always mean a 3.3V battery. I had the BAT jumpered, and then I tried with and without the REG jumpered.
At the same time, I believe I damaged the MCP1700 regulator - I will have to take it off and test it.
So in the interest of getting this resolved quickly, I started all over again with a new board, new regulator, and jumping only REG. It worked! Here is the picture:
You can see that the radio will get 3.3V, and the rest of the board will get 4+ volts. (The TP4056 will cut it off as it goes down to around 3V).
So I will continue the build, and if everything goes according to spec, the radio, arduino, and sensors should all be OK. (Assuming the sensor can handle 4+ volts).
As far as the capacitors, it looks like the spec says 1uF on input and output. So I will put those where there are labels for .1 and 10uF. For the radio, I am well aware of its capacitor needs (learning the hard way). At this point, I always put the 4.7uF cap directly on the radio.
If everything goes well, I would recommend putting some sort of reference to LIPO batteries in the instructions. I couldn't be the only one who wants to do this.
Great support from everyone!
There's not much to the wiring (maybe that's my problem?).
To attach the legs to be like a LE33, I swung the Vout of the MCP1700 all the way to the left.
With a multimeter, I see 4.1 volts at the radio, and everywhere else.
Thanks!
Yes, I agree. I didn't look closely enough at the currents for le33. The general rule of thumb seems to be:
Current in "milli"amps -> only days or weeks for a battery
Current in "micro"amps -> months on a battery
So MCP1700 seems to be right for a LIPO here.
I did test it on a breadboard. And then I built a little regulator board. It works great.. and I used a battery from an old cell phone that stills seems to work well.
@sundberg84
I did adjust to the different pinout. I checked it multiple times, checked soldering - it always seems like the regulator is not regulating anything - the radio always gets 4.1 volts from the LIPO.
From looking at the specs, the LE33 is pretty close - with the biggest difference that the MCP1700 can handle more current.
Maybe I should just get the LE33 ones.
Oh well...
Regarding the MCP1700 as a regulator (I ordered these: https://www.aliexpress.com/item/5-pcs-MCP1700-3302E-TO-MCP1700-Fixed-LDO-Voltage-Regulator/32781100568.html)
first connected the LIPO->TP4056->MCP1700 to the GND and PWR of the board. (I made a homemade little regulator board). From all appearances, it works great, and I end up with a nice compact sensor/battery. But I want to make use of the Easy/Newbie board. I tried hooking it up to the 3 pins marked regulator, but it didn't seem to do anything. Am I missing something? The orientation can be confusing, but I think I got it right. I measured 4.1 volts to the radio, which will fry it.
Thanks!
At least according to the specs, mcp1700 will do the trick (both in terms of drop out voltage and low power consumption for battery usage). I will try it.
Hi -
I wanted to know if this config is OK:
Attach a LIPO battery to PWR and GND.
Cut off the right side of the board.
Use a 3.3V pro mini.
Add a regulator (like a MCP1700) and necessary caps. (Spec says 1uF).
The idea is that the board and sensors get 3.2V - 4.1 V (which should be OK).
The radio gets 3.3V.
Thanks!
is "isTransportOK()" obsolete in 2.1.0 ?
Re: Battery sensor and re-connecting to gateway
Consider this:
It's not as cheap as a TP4056, but it allows you to choose between battery technologies.
I know little about hardware design, but I will comment on the TP4056 :
I originally planned on using a LIPO battery with a TP4056, but then read that the batteries can't withstand cold weather. (I wanted it for a mailbox). Could the board also support the newer, LifeP04 batteries? There is probably an interface board for those too, and they would be more efficient because you don't have to regulate the voltage (they operate at 3 V).
Thanks
It's definitely easier with a booster - but not cheaper or more reliable. (Why does the booster cost more than the Arduino?)
Everything is about tradeoff's. When you solve one problem, it can easily introduce another. At first, I ignored the whole booster thing. But after a lot of experiments, I ended up with a pile of 1.35 V batteries. So I tried the booster, and ended up with transmission problems (partially solved by capacitors). So then I tried changing the bootloader (1Mhz, no brown out), and it seems to be OK - but I know there will be other problems. Example: I now need to boost to 3.3V for sensors that require it. Also, are there compatibility problems with mysensors?
Even still, thanks for the great board - I've had a lot of fun and learned a lot with it!
I took a chance and tried these boosters. After adjusting the pot to boost to 3.3V, and using wires to connect, they seem to work the same as the "recommended" ones. I am hoping they produce less noise for the radio - I seem to have trouble with that, even with adding the capacitors. (Maybe my radios are not good).
Another experiment - boosting them to just over the 2.8V fuse limit. I would think that would be more energy efficient.
Has anyone tried one of these boosters:
I'm not sure, is there a problem using them with the PCB boards? I imagine the input and output ground would have to be connected together.
Thanks!
In the "Create Repeating Nodes" section, could you please change:
#define MY_REPEATER_NODE
to
#define MY_REPEATER_FEATURE
I wasted a lot of time trying to figure out why my repeater node wasn't working.
Thanks for a great product!