DIYino Prime v1.5 - a micro power saber board

[Obi_1]

I'm happy to announce that there is a new member in the DIYino family of Arduino compatible DIY boards for saber and other DIYs involving Motion/Light/Sound:

DIYino Prime v1.5

This board is a spin-off of the v1, keeping all features and adding new ones. The main design goal for the v1.5 were:
- design a board with an overall current consumption of less than 1mA in sleep mode in order to enable long shelf life without kill-key
- allow access to UART and SD-card over the same USB interface
- route out signals for advanced usage/development purposes
- reduce the board size
- put in all learnings from v1, feedback from users etc.

New Features:

1. Micro power board: AFAIK this is the first saber board capable of being supplied with a voltage >5V (i.e. for LED strings or HP-LEDs) and consumes less than 1mA in sleep mode. Currently with the new power saving hardware options I measured ~500uA in sleep mode, going lower if using a supply under 5V. I wanted to have this feature to enable building Arduino based sabers without the need to constantly plug in a kill-key, therefore pawing the way for an internal RC port or alternate charging method.
2. Single interface board: both the SD-card and the programming interface can be accessed over a single USB-plug. No need to remove SD-card if wanting to exchange sound fonts. Additionally the 4 USB signals are available as breakout signals, so an external USB-connector can be worked in into the hilt to enable in-hilt programming without removing any part of the hilt.
3. Swap mini-USB for a micro-USB port, reducing the height of the board and saving space.
4. Acess to a lot of internal signals for tech-fans (DAC signals, internal LDOs etc.)
5. Pre-wired connections for those features which were recognized as essential (i.e. audio controlled flicker), reducing the amount of intra-board wires necessary for full operation with current open-source saber software.
6. Slight reduction of board size (this was not a design goal, as the v1 is small enough, and mainly comes from the swap of the USB-connector)
7. Comes with the Arduino Uno bootloader, adding 1.5k of program code space.

What stayed:

- still can used to build all commonly used saber blade types i.e. Luxeon type with HP-LED, segmented LED-strings and neopixel blades.
- high-quality audio using wav files compatible with PL boards format from SaberFonts
- advanced 6-axis gyro- and accelerometer for movement and gesture recognition
- Arduino compatible with Atmega328P avr microcontrollers
- all current open-source saber software will run on the v1.5 without need for change (except for the board type, but I can burn them as Nano if needs be)

Note: I currently do not plan to start runs of the v1.5, it being still intensively characterized. I consider it as an intermediate step between v1 and a future v2. I might be offering some of the few pieces I have for sale for those who are willing to experiment with its power saving options i.e. the main target group is LED-string saber enthusiasts, using higher supply voltages for serialized LED setup, where the unique features of this board can be utilized fully.

[jbkuma]

Very nice and welcome updates.  Breaking out the USB is a very welcome addition, with the common USB for the uSD it's pretty close to perfect.

[EXAR KUN]

This is wonderful! Some really great improvements.

My favorite new thing is probably the USB interface so you don't have to remove SD for soundfont changes. That is pretty amazing.

I'd love to try this one out, however I've not tested out your V1 board yet as I haven't had time. Although I am now close to having some free time soon to play with the Neopixel and segmented blade options for this. I love how it's smaller, too. Even though not a design goal for you,... you do know how fast room can disappear inside a saber!

[JakeSoft]

Ooo... it might be worth it for me to add some power management features to USaber. And 1.5K more program space!? I'm sure I can find a use for that!

[JakeSoft]

I'm curious if your measurements were taken with just the AVR chip in sleep mode, or was the sound chipset sleeping also? I noticed there is a sleep serial command in the spec for the sound chip, but I've never tried to use it. It's almost ridiculous how easy it is to put the 328P to sleep.

[Obi_1]

No, actually it was a bit more tricky. I tried that command but could never see any effect on the current consumption. So I choose to implement the current saving options for UART and MP3 in hardware.

If you only put the AVR to sleep mode, you will still end up with 30+ mA of current consumed, mainly by the MP3, the FTDI and the audio amp.
To put it in simple terms: I cut the power to the modules. It's on-board power management  This is actually - without going into the details - how the single USB can be used to serve multiple chips.

And there is also a trick on the LDO side when powering with >6V to avoid the ~10mA consumed by the LDO...

[JakeSoft]

No, actually it was a bit more tricky. I tried that command but could never see any effect on the current consumption. So I choose to implement the current saving options for UART and MP3 in hardware.

If you only put the AVR to sleep mode, you will still end up with 30+ mA of current consumed, mainly by the MP3, the FTDI and the audio amp.
To put it in simple terms: I cut the power to the modules. It's on-board power management  This is actually - without going into the details - how the single USB can be used to serve multiple chips.

And there is also a trick on the LDO side when powering with >6V to avoid the ~10mA consumed by the LDO...

That's even better. More done with hardware trickery means less code space eaten up with power management functions.  I assume documentation about how to access these new features will be coming in the future. Right?

[Obi_1]

This is wonderful! Some really great improvements.

My favorite new thing is probably the USB interface so you don't have to remove SD for soundfont changes. That is pretty amazing.

I'd love to try this one out, however I've not tested out your V1 board yet as I haven't had time. Although I am now close to having some free time soon to play with the Neopixel and segmented blade options for this. I love how it's smaller, too. Even though not a design goal for you,... you do know how fast room can disappear inside a saber!

Hi Anthony, thanks for the kind words! The single USB interface is also something I definitely see as an option with many possibilities. Combined with signals to lead the USB connector to the saber hilt like an RC-port can allow for a setup in which the saber board can be fully interacted with without the need to disassemble it.

And indeed, room can disappear inside a hilt with alarming speed, the reason I mentioned that it was not a design goal is that I still try to find an answer to the question how to improve the size and for that I'm grateful for input. The v1 I designed to be not longer than a 18650 battery so that in the hilt it can ride on the battery. Having made some sabers I'm now reconsidering this goal: it will work with an MHS hilt all right, because of the nice spacious room inside, but many other hilts out there have an ID so that piggybacking the board on the battery is less of an option. Unless the board is made more narrow, so that it can still ride on the battery. In which case the board could extend a bit in the length, because considering the wirings the battery will be anyway longer than the typical 65mm...

But these are only my humble considerations, I would like to hear what others think about the size that does matter.

[jbkuma]

In the interest of convenience, if it's about 20.5mm x 55.5mm it would fit in the TCSS v6 speaker mount.  Judging from the v1 board and the photo, it looks like it will fit comfortably. 

I'm also looking forward to that code space expansion.  My current LSOS revision is about 93% of code space, so I can see the benefit of some breathing room there.  Jake, you may appreciate that I'd like to use some of that for serial menus. 

[JakeSoft]

I'm also looking forward to that code space expansion.  My current LSOS revision is about 93% of code space, so I can see the benefit of some breathing room there.  Jake, you may appreciate that I'd like to use some of that for serial menus.

I had the exact same thought. My USaber-based sketch is at 90% capacity. The extra room might give me just enough program space to add something like that.

[Obi_1]

I wish we could have more dynamic memory as well. Looking at what Jake did with the USaber code size compression, I'm pretty confident that existing code can be optimized to save more for even more FX.

[JakeSoft]

I wish we could have more dynamic memory as well. Looking at what Jake did with the USaber code size compression, I'm pretty confident that existing code can be optimized to save more for even more FX.

There is still room for optimizations on that front as well, but mostly on the 3rd party libraries that USaber includes. The MPU6050 library is HUGE. It adds about 6K to the sketch size! By comparison, the ADXL335 motion management code adds only around 1K.

[jbkuma]

Have you considered using a different chip like a 644 or a 1284?  I just ordered a 1284 board to play with.  There's obviously some other changes that'd have to be made, but the 644 will give you double the program memory and SRAM, the 1284 is 4x the memory and 8x the SRAM.  There is also twice the EEPROM and 9 more I/O pins which may be less important, but I wouldn't hate having more pins to make use of that programming and ram space :D

[Obi_1]

The current version is v1.5 to emphasize it's an intermediate step on the journey from v1 to v2. That is why I do not start any bigger run of this device. Learning from this one I assume I settled for everything except the controller. Therefore I open up the discussion which controller we should be using in v2!

Prerequisite is that the controller must have available boot loader and has power saving options allowing it to go to sub-mA deep sleep mode.

[jbkuma]

I just ordered one of these to play with.  It lists a 6.8μA draw in sleep mode.
Mini ATmega1284P-AU Breakout Small form factor very low current draw.