💬 Stamp size MySensor node




  • Hardware Contributor

    nice, your tqfp seems well soldered 😉



  • Very good ! So small !
    I really need to learn how solder SMD part ! More and more design are using small components.


  • Hardware Contributor

    Well done! Nice!



  • Hello,

    I have a question about the dimensions. Could you tell me what is the exact measure when fully assembled with nrf24 and with / without goldpins? I have tiny, transparent boxes and curious if I can fit them inside 😄


  • Hardware Contributor

    @macieiks

    The pcb itself is 21 mm wide and 23 mm long.

    With the radio the longest side becomes 30 mm long and 21 mm wide.

    Without any pins mounted, the board is just under 5 mm think.

    If the dual row angled headers are mounted, the longest side (30 mm with radio) becomes 39 mm.
    You will need to add the length of the contacts + wire to that for a complete length.

    You can also turn the dual row angled header inwards (towards the radio), then the maximum length is still 30 mm.


  • Hero Member

    @GertSanders What is the difference between the v1 version of your stamp size mysensor node that's on OSH PARK and the V2 version that's on your website that you linked to in your OP ( https://www.openhardware.io/view/76/Stamp-size-MySensor-node )?


  • Hardware Contributor

    @NeverDie
    None. The plan was to enhance it, so I copied my version 1 to version 2. But then I decided to publish it in Openhardware anyway.
    This board is a proof of concept for me.
    My next version will have a 8Mhz crystal. The addional powerconsumption is negligable bit the accuracy of timing is much better (and constant, even with dropping voltage).
    So the board on OSH Park is identical to the one on Openhardware.io


  • Hero Member

    Thanks! I ordered it yesterday from OSH PARK, so good to hear.

    Have you found something where you really do need the 8mhz crystal oscillator, or were you adding it as a "just in case"?


  • Hardware Contributor

    @NeverDie
    I have a use case where I need the clock to be acurate. For realy low power nodes like the ones with reed switches, I also prefer the internal oscillator.



  • @GertSanders

    Goedenavond Gert,

    What's your boards.txt file is saying please? I uploaded the bootloader (optiboot_atmega328_08M_038400_D8) and all went OK until I upload my first sketch.
    After that I am getting:

    avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x32
    avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x0f
    avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xfb
    avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x32
    avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x0f
    avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x73
    avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xff
    avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x32
    avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x0f
    avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfb
    

    I have to upload the bootloader again in order to upload the sketch - something is clearly not working. This is my extract from boards.txt:

    BlueBoard.menu.mhz.8Mhz= 8Mhz - internal oscillator D8 LED for atmega328-tqfp
    BlueBoard.menu.mhz.8Mhz.bootloader.low_fuses=0xE2
    BlueBoard.menu.mhz.8Mhz.bootloader.high_fuses=0xDE
    BlueBoard.menu.mhz.8Mhz.build.f_cpu=8000000L 
    BlueBoard.menu.mhz.8Mhz.upload.speed=38400
    BlueBoard.menu.mhz.8Mhz.bootloader.file=myoptiboot/optiboot_atmega328_08M_038400_D8.hex
    

  • Hardware Contributor

    @alexsh1

    Here is my extract for this type:

    32PinBoard.name=atmega328p based - 32 pin TQFP
    
    32PinBoard.upload.tool=arduino:avrdude
    32PinBoard.upload.protocol=arduino
    32PinBoard.upload.maximum_size=32256
    32PinBoard.upload.maximum_data_size=2048
    
    32PinBoard.bootloader.tool=arduino:avrdude
    
    32PinBoard.bootloader.unlock_bits=0x3F
    32PinBoard.bootloader.lock_bits=0x0F
    
    
    32PinBoard.build.core=arduino:arduino
    32PinBoard.build.mcu=atmega328p
    
    32PinBoard.build.board=AVR_GERTSANDERS32PinBoard
    32PinBoard.build.variant=32PinBoard
    
    32PinBoard.menu.bod.4v3=4V3
    32PinBoard.menu.bod.4v3.bootloader.extended_fuses=0x04
    32PinBoard.menu.bod.2v7=2V7
    32PinBoard.menu.bod.2v7.bootloader.extended_fuses=0x05
    32PinBoard.menu.bod.1v8=1V8
    32PinBoard.menu.bod.1v8.bootloader.extended_fuses=0x06
    32PinBoard.menu.bod.off=Disabled
    32PinBoard.menu.bod.off.bootloader.extended_fuses=0x07
    32PinBoard.menu.mhz.8Mi-38K4-D8= 8Mhz - internal - 38K4 - D8
    32PinBoard.menu.mhz.8Mi-38K4-D8.bootloader.low_fuses=0xE2
    32PinBoard.menu.mhz.8Mi-38K4-D8.bootloader.high_fuses=0xDE
    32PinBoard.menu.mhz.8Mi-38K4-D8.build.f_cpu=8000000L 
    32PinBoard.menu.mhz.8Mi-38K4-D8.upload.speed=38400
    32PinBoard.menu.mhz.8Mi-38K4-D8.bootloader.file=myoptiboot/optiboot_atmega328_08M_038400_D8.hex
    


  • @GertSanders OK, the issue is in pins_arduino.h in 32PinBoard folder. The standard file is just not good. I'll have to find the right one for tqfp chip.

    EDIT: copied the "eightanaloginputs" variant in the variant folder, but still can only upload the first sketch after the bootloader, all other uploads are giving me "avrdude: stk500_getsync() attempt x of 10: not in sync:"



  • @GertSanders Gert, what pins_arduino.h are you using for this board please? Can you post it here?


  • Hardware Contributor

    @alexsh1

    Here is the pins_arduino.h file for the 32pin TQFP package

    0_1465854245099_pins_arduino.h


  • Hardware Contributor

    @alexsh1

    And here is a ZIP file with my complete atmega328p definitions

    0_1465854396475_atmega328p.zip



  • @GertSanders Many thanks for your help. This is probably my bad luck, but I have mixed up C1 and R1 mounting them vertically (not horizontally). What a stupid mistake really given that I have checked it a few times. Anyway, now everything is working.

    FYG, I looked at your pins_arduino.h - this is a standard one and it is not correct. I corrected the following entries:

    static const uint8_t SS   = 14;
    static const uint8_t MOSI = 15;
    static const uint8_t MISO = 16;
    static const uint8_t SCK  = 17;
    
    static const uint8_t SDA = 27;
    static const uint8_t SCL = 28;
    #define LED_BUILTIN 8
    
    static const uint8_t A0 = 23;
    static const uint8_t A1 = 24;
    static const uint8_t A2 = 25;
    static const uint8_t A3 = 26;
    static const uint8_t A4 = 27;
    static const uint8_t A5 = 28;
    static const uint8_t A6 = 19;
    static const uint8_t A7 = 22;
    

  • Hardware Contributor

    @alexsh1
    OK, I will check also on my side 🙂 Thanks for the feedback.



  • @GertSanders No worries! And signing works flawlessly on this node as well with ATSHA204A by the way 🙂



  • 0_1466010177286_image.jpeg


  • Hardware Contributor

    @alexsh1
    Double plus good !
    As I have no signing capability on my raspberry-turned-gateway I'm glad the hard work to simplify signing was done so well by @tbowmo and @Anticimex. Even without testing it I could assume it would work.


  • Contest Winner

    @GertSanders You are welcome 🙂 Btw, if you just patch in support to generate random data for a nonce, you can use the soft signing backend on rPi.


  • Hardware Contributor

    @Anticimex
    Well that sounds simple, but I'm more a hardware contributer, this is beyond my capabilities :-), especially in unix arena. I manage software developers for a living, so I know how much I do not know.



  • Hello guys,

    I am about to solder first PCB of this version. Just to be 100% sure, regarding C4 - what is the best value to use 1uF or 10uF, because I can see we can choose.

    Regards,
    Maciek


  • Hardware Contributor

    @macieiks

    Better to use 10uF. The schematic needs to be updated (still shows 1uF, I use 10uF now).



  • @GertSanders

    Thank you for the update,
    Last part what I am missing is battery holder. I was trying to search it in many stores located in my country however I was not able to get it. Is there any internet shop when I can buy online? I have one workaround to soldier different CR battery holder and connect via wires.



  • @macieiks I bought the battery holder on http://www.ebay.co.uk/


  • Hero Member

    @alexsh1 The link directs me to ebay home page... (possibly a country issue) can you give the name of the item so I can search?



  • @AWI I just put a link to an eBay. You put "Keystone 3013" in the search and hit search 🙂

    http://www.ebay.co.uk/itm/KEYSTONE-3013-BATTERY-THM-RETAINER-16MM-/271911714571?hash=item3f4f337f0b:g:PsQAAOxyx-BSa7y-


  • Hero Member

    @alexsh1 👍 (although pretty expensive...) building on your reference I found this
    Should do the job..


  • Hardware Contributor

    @alexsh1 do you plan to use this so small coincell with rfm69? very curious to see results regarding internal res during RX-Tx times...1.8V brownout should not be far i think..or maybe not 🙂 because the voltage won't stay at 3v 😉 but to counter effect, a nice capa at input with a current limiting resistor could help. reading/waiting voltage stabilize before transmitting can help too (I'm doing this with some CR2032 based nodes)



  • @AWI I only needed one or two and ordering 30 despite it is cheaper per unit, was probably too much for me.



  • @scalz Yes, that's the plan, but I think I'll come across many difficulties. For now I have the nrf24l01+ version fully working. And started scratching the surface with RFM69. This is nrf24l01+ SMD version and swapping it for RFM69 is not going to be easy. So far I have not seen any adapters for the SMD version.



  • I have just updated a stamp size node to MySensors 2.1.1 and had to include the following into the sketch:

    #define MY_RF24_CE_PIN 9
    #define MY_RF24_CS_PIN 10
    #define MY_SOFTSPI
    #define MY_SOFT_SPI_SCK_PIN 13
    #define MY_SOFT_SPI_MISO_PIN 12
    #define MY_SOFT_SPI_MOSI_PIN 11

    The fist two lines are not required (it is in the MyConfig.h), but for me to understand how nrf24l01+ is connected.
    I hope it helps

    Regards
    Alex



  • Hi @GertSanders, @alexsh1

    I'm considering to build a few nodes with this design, could anyone that have done and tested these give some feedback on how it work? Battery life etc. In my case I will mostly use it as window/door sensor and water leakage sensor so it would not send data to frequently.

    Thanks for any input.


  • Hardware Contributor

    @GertSanders,
    Thank you for the nice, small design. I'm trying to build one myself, but I'm running into issues burning the bootloader using the ArduinoISP sketch on an Arduino Nano (328). Looking at the schematics, the pins of the ICSP header (from left to right, if the headers are facing you) are:
    Reset => Pin 10 of Nano
    SCK => Pin 13 of Nano
    MISO => Pin 12 of Nano
    MOSI => Pin 11
    VCC => VCC on Nano
    GND => Gnd on Nano

    I set the board to Arduino Pro or Pro Mini in the Arduino IDE, selected Arduino as ISP and tried to burn the bootloader, but there always is the error message:

    avrdude: Expected signature for ATmega328P is 1E 95 0F
    Double check chip, or use -F to override this check.
    Error while burning bootloader.

    Any idea what's wrong?

    I built two copies of the board, and I get the same message with both. (mirroring the connectors of the ICSP header doesn't work, either).

    Thanks a lot!


  • Hardware Contributor

    @reinhold
    Hi, the first thing I would check is to see if you can burn a boot loader on a standard 328P DIP format with the Nano. I'm not sure the ISP sketch, when running on a Nano matches the exact physical pins for MISO, MOSI and SCK. So check that.
    I also burnt the boot loader with the sketch, but on a classic Arduino UNO as ISP. Never tried to do this from a Nano as ISP.


  • Hardware Contributor

    @reinhold
    Something else I was thinking about. I did burn the boo loader before I mounted a NRF24L01+ board on my stamp size board.
    I made another board recently and found that burning a boot loader while the radio is connected, gives me issues like the one you mention: sometimes an unexpected signature error, sometimes it starts and stop loading midway ... That was on a different board, but with basically the same connections between processor and radio.
    So I think that you do need to load the boot loader before mounting the radio on the board. As for my newer board where I first found this issue, it was a robot control board I now need to redesign so that I can refresh the boot loader (ro anything else via ISP) with a mounted radio, by providing a "switch" of some kind to isolate the radio when I do not want it to interfere with the ISP loading.



  • @henninne sorry for a late reply. The battery life is excellent. I have one node working as a door sensor and another one I'm testing as a battery voltage sensor - just sends voltage every 60 mins. The door sensor is powered by two AAA batteries and has been working for 5-6 months and still shows 3.1V+
    The battery sensor is running on a coin cell and consumes around 6uA while sleeping.



  • @reinhold The error message means that AvrDude could not communicate with target processor. Ttiple check your wiring. Can you try a different target board to make sure Nano works as expected?


  • Hardware Contributor

    @GertSanders Thanks for the response.
    I had already used the nano to install the bootloader on the linbus analyzer and linbus injector boards, so apparently the nano can be used with the ArduinoISP sketch. I also tried re-installing a bootloader to another nano via the ICSP pins and it worked.

    I also tried building my last PCB for your stamp-sized nodes without the wireless module installed, but I get the exact same behaviour. (You are right, it's not so far-fetched that the radio module might interfere with the bootloader installation, since the ICSP header also just breaks out the SPI headers. On the other hand, the slave select for the nrf24l01+ is not pulled low by the arduinoISP, so it should not interfere on the SPI bus...).

    @alexsh1
    I already tripple checked my wiring (even tried switching MISO/MOSI), but I can't find any problem. In fact, only with this very wiring do I get the "Expected signature for ATmega328P is 1E 95 0F" error message, as only with this wiring, the signature is different from 0x000000. Here's the verbose log of the bootloader burning:

    https://pastebin.com/Lw3Ri6wg

    Strangely, I do not get the same signature when I try to burn the bootloader again (0x040404 => 0x0e0808 => 0x080808; 0x820202 => 0xc10101 => 0x820202).
    So it seems that communication is somehow possible, but only garbage is observed.

    FWIW, I'm using the "Arduino Pro or Pro Mini" (like I did with the linbus boards) with processor ATmega328P (3.3V, 8MHz).

    The only difference I can see between the working linbus and nano boards and this stamp-sized node is that the linbus boards have an external crystal, while this stamp-sized node appears to use the internal crystal of the chip. Can this be the difference?


  • Hardware Contributor

    The bootloader burning issue was indeed a problem with the crystal: It seems that the atmega328p that I bought on aliexpress came with the fuse set to external crystal, so they worked fine on all boards with an external crystal, but this stamp-sized node didn't react because the internal oscillator was disabled in the chip. I had some 16MHz SMD crystal lying around, soldered jumper wires to them and manually held them to pins 7 & 8 of the atmega328p while trying to burn the bootloader. That's quite delicate as the pins are so small, but it works astonishingly well.
    As boards I used the "MiniCore atmega328" board that allowed me to select the internal crystal and also lower the black-out voltage.

    With the external crystal held to the atmega's pins, I was able to properly burn the bootloader and activate the internal oscillator. Now, the board seems to work just fine.
    The only issue is that I just realized I don't have any CR1632 batteries. I suppose CR1620 will also work, but that a shorter battery life?

    Thanks again,
    Reinhold


  • Hardware Contributor

    @reinhold
    Glad you found the issue. I'm not sure there are 1616 batteries, but two on top of each other might fit ?


  • Hardware Contributor

    @GertSanders Am I missing something, or wouldn't two 3V batteries in series fry the atmega and in particular the nrf24 with 6V?


  • Hardware Contributor

    @reinhold
    Totally correct. Very dumb suggestion on my part. You would get 6V, which is above spec for the atmega328p and the nrf24



  • what about adding a step-up converter to drain the battery more? or does it waste too much power?

    thx for design and this small battery powered node 😉



  • I think for this node an ISP programmer is needed. It might be nice, if you can put a notice for that on mysensors.org.

    Maybe also mention that you should not use the VCC of your programmer. In most cases it will deliver 5V which will fry the NRF chip 🙂



  • another thing, I ordered the PCB at OSH park...

    Is there any possibility that you and/or MySensors will gain something (affiliate)?

    the pin holes are a bit small for standard pin headers. Would be nice if you could increase the diameter a bit on version 3 🙂


  • Hardware Contributor

    @krisha
    I use a 3V3 programmer. I also use standard pin headers, they fit without a problem.



  • @GertSanders
    ok, strange. standard pin headers fit for me only into FTDI and ICSP pin holes. Into the other two 8 pin rows it does not fit.



Suggested Topics

67
Online

11.4k
Users

11.1k
Topics

112.6k
Posts