fiduciary

Author Topic: Announcing the Teensy Saber open source sound board  (Read 91582 times)

0 Members and 1 Guest are viewing this topic.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #45 on: January 21, 2017, 04:06:26 PM »
The delay(1000) turned out to be a red herring.
It seemed to work better because it printed out more things, but then just hung while scanning.
The problem is apparently that SD.open() hangs if you give it a filename with a trailing slash, which I was doing...
(The same thing happens if you type "dir font01/" in the serial monitor.)
I've uploaded new version (1.20), which avoids using paths with trailing slashes. Let me know if it works better for you.

Offline theholyduck

  • No Force
  • *
  • Posts: 40
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #46 on: January 21, 2017, 08:29:15 PM »
http://fredrik.hubbe.net/lightsaber/lightsaber-1.20.ino this does seem to work yes. no more hanginng with both sd and audio

Offline twing207

  • No Force
  • *
  • Posts: 6
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #47 on: January 22, 2017, 09:26:15 AM »
Would it be possible to port this code to a different microcontroller? Like the Atmega32U4 or the SAMD21. The teeney chips are too proprietary to make for great open hardware projects.

Offline JakeSoft

  • Experienced Force User
  • ****
  • Posts: 393
  • The Arduino Jedi
    • Universal Saber Library
Re: Announcing the Teensy Saber open source sound board
« Reply #48 on: January 22, 2017, 11:05:37 AM »
Would it be possible to port this code to a different microcontroller? Like the Atmega32U4 or the SAMD21. The teeney chips are too proprietary to make for great open hardware projects.

A board and open source code already exist based on 8-bit AVR MCU.

See World's first Arduino lightsaber board - DIYino v1

The Teensy code won't port directly and work well anyway because the 8-bit AVR chips don't have enough grunt to do all that audio processing with high-fidelity playback. The solution above offloads the audio processing to a separate chip.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #49 on: January 22, 2017, 11:11:01 AM »
Would it be possible to port this code to a different microcontroller? Like the Atmega32U4 or the SAMD21. The teeney chips are too proprietary to make for great open hardware projects.

Probably, the requirements are fairly generic:

1. The chip has to be fast enough
   (Not sure how fast it really needs to be though, I don't think I'm using all that much of what the teensy
    can do right now...)
2. It needs DMA or a programmable IO engine to drive audio and neopixels.
3. It needs enough RAM for audio buffers (32kb *may* work, teensy has 64kb, and I use quite a lot of it...)
4. A proper DAC will produce better audio than a PWM-based "analog out", not sure how much that matters though.
5. Needs i2c and SPI to talk to motion chip and sdcard (but I think all MCUs have that...)
6. It needs to fit in a lightsaber. :)

I wouldn't want to try porting the teensysaber code to something that uses an external audio chip though. It would just be too different.

The Atmega32u4 wouldn't work, it just doesn't have enough RAM.
The SAMD21 looks more promising, but I might have to reduce the number of audio mixing channels to be able
to fit in 32kb RAM.


Offline twing207

  • No Force
  • *
  • Posts: 6
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #50 on: January 22, 2017, 06:05:53 PM »
I would very much like to try designing an open source board with the SAMD21 chip in it to run this software. Although ideally it would be better to use an external DAC something like the MCP4725 than a PWM for sound output. How much of a task would it be to make this software work with an external DAC and use the SAMD21? I could design a single board to contain all the parts together and do a small run of them for anyone else interested.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #51 on: January 22, 2017, 07:27:19 PM »
MCP4725 looks easy enough to work with. It's the integrated sdcard-to-audio solutions that I don't want to try to port to. If possible, try connecting the MCP4725 to it's own i2c bus, as that simplifies driving it from an interrupt a great deal.

Offline twing207

  • No Force
  • *
  • Posts: 6
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #52 on: January 23, 2017, 07:43:10 AM »
Let me ask , would it be possible to compile the hex of the existing software and then install it directly onto a blank MK20DX256 without the teensy bootloader using an ISP?  If I'm not mistaking the bootloaders only job is to allow the uploading on new sketches?

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #53 on: January 23, 2017, 08:48:26 AM »
Let me ask , would it be possible to compile the hex of the existing software and then install it directly onto a blank MK20DX256 without the teensy bootloader using an ISP?  If I'm not mistaking the bootloaders only job is to allow the uploading on new sketches?

Yes, but being able to upload through USB is a in important feature IMHO. I think there are alternative bootloaders available though.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #54 on: January 23, 2017, 09:21:30 AM »
Let me ask , would it be possible to compile the hex of the existing software and then install it directly onto a blank MK20DX256 without the teensy bootloader using an ISP?  If I'm not mistaking the bootloaders only job is to allow the uploading on new sketches?

Yes, but being able to upload through USB is a in important feature IMHO. I think there are alternative bootloaders available though.

Actually, if I was working on an integrated design with cpu on board, I would probably replace the SD card with a large SPI flash chip. (At least 64Mb)  SPI flash chips tend to be much faster and would make audio mixing easier and less RAM-intensive. However, I would have to implement one of the USB storage standards to make it easy to add/remove files from the flash chip. As an additional bonus, the board would become a fair amount smaller by removing the sd card slot.

Offline twing207

  • No Force
  • *
  • Posts: 6
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #55 on: January 23, 2017, 09:43:24 AM »
Let me ask , would it be possible to compile the hex of the existing software and then install it directly onto a blank MK20DX256 without the teensy bootloader using an ISP?  If I'm not mistaking the bootloaders only job is to allow the uploading on new sketches?

Yes, but being able to upload through USB is a in important feature IMHO. I think there are alternative bootloaders available though.

Actually, if I was working on an integrated design with cpu on board, I would probably replace the SD card with a large SPI flash chip. (At least 64Mb)  SPI flash chips tend to be much faster and would make audio mixing easier and less RAM-intensive. However, I would have to implement one of the USB storage standards to make it easy to add/remove files from the flash chip. As an additional bonus, the board would become a fair amount smaller by removing the sd card slot.


Yea I like the idea of flash on board. Being able to upload the sketch is ideal, but I was not aware of alternative bootloaders. If you are interested in working on such a board shoot me an email. I would like to design a new board as an alternative to the expensive boards currently available. I have the equipment to make production pcbs including double sided SMT. 

Offline twing207

  • No Force
  • *
  • Posts: 6
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #56 on: January 24, 2017, 06:57:37 AM »
Do you use both the accelerometer and the gyro in your code or only the accelerometer?

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #57 on: January 24, 2017, 08:46:27 AM »
Do you use both the accelerometer and the gyro in your code or only the accelerometer?

I use both.

Offline theholyduck

  • No Force
  • *
  • Posts: 40
  • Um...Hello?
Re: Announcing the Teensy Saber open source sound board
« Reply #58 on: January 25, 2017, 04:03:16 AM »
Would it be possible/are you planning too add user programmable pwn "drive" for the mosfets on a per detected blade type level? for instance. i have a set of leds whos factory rated voltages are 3.2-3.6v where as my battery will run from 4.2 to 3.0 or whatever. you can run these without a resistor but its not ideal. meanwhile resistors themselves are not ideal either. especially when you are talking really big powerful led strings.

a possible solution for this as i understand it is to reduce the pwm on time to the mosfets to let those bleed the excess voltage instead. at least for small drops like driving green/blue in parallel on 1 18650 or green/blue in series on 2 18650s. or 3 reds in series on 2 18650s.

I could probably hard code in specific pwm rate which is safe for 1 blade but im not much of a programmer and it seems like it could be pretty useful to implement a universal version of this. it would allow driving led stars and various types of led strings without resistors. and you could also potentially make the on time increase as battery voltage decreases thereby maintaining a consistent brightness for longer. also this would allow for some flash on clash effects for single string blades by temporarily over driving the string to boost brightness. and finally it would allow introducing some blade shimmering to the simple blades.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Announcing the Teensy Saber open source sound board
« Reply #59 on: January 25, 2017, 08:40:47 AM »
I have been considering this, but I have not implemented it yet.
In fact, I think there are three different ways to implement this.....

A) The first way I considered was to use an actual hardware feedback loop.
   This would be a true constant-voltage drive. However, it turns out to
   be somewhat difficult to implement, and the FET would have to absorb the
   extra voltage, making it heat up and possibly damage it.

B) The second way is to use a very very fast PWM signal to achieve something
   similar. Since the gate on the FET is basically a capacitor, it would smooth
   out the PWM signal. However, I don't think that would work well because the
   transition region for the FET can vary from transistor to transistor, so without
   a feedback loop there is no way to know exactly what the output voltage would be.
   And, even if it worked, the FET would still heat up a lot.

C) The third way is to stay at the same PWM rate as before, but simply reduce the
   time we spend in the "on" state per cycle if the voltage is too high.
   Basically, if your led is made for 3.8 volt, but the battery is currently at 4.0 volt,
   we would turn the PWM to 3.8/4.0 = 95%. The LED would still get hit with the full 4.0
   voltage, but hopefully it wouldn't over-heat and die since it's not on 100%.
   Doing it this way would prevent the FET from over-heating, but I also don't know how well it
   works. LEDs are non-linear and turning it off for 5% of the time might not be enough to
   protect it from dying. It might also affect the brightness and color of the LEDs in ways
   that could be annoying. (Or not, I simply don't know yet.)

For my setup, I use resistors to bring down the voltage a bit to match the LEDs, but I
use the nominal voltage of the battery (3.7 volts) for the resistor calculations. Since
the voltage of the battery is often higher than this when fully charged, I was thinking
that using one of the solutions above might be good. But as I said: I have not actually
tried this yet. Option (C) would be fairly easy to implement though.

 

retrousse