Prop Shield Beta Test

Status
Not open for further replies.
Hmmm... the Mac version might have a problem with lingering after quit, perhaps preventing a Mac from shutting down without a force quit. Maybe? Or maybe that was an older copy lingering on my mac?

If anyone with a newer Mac can test, please let me know?
 
I've been debating whether or not to find someone in the 501st or Rebel Legion who looks like a good candidate to send a Prop Shield to do just that. :)

It probably wouldn't hurt to ask. I was curious, because I hadn't seen much about light saber build requests recently.

In early 2015, there was this post by forstyjr: https://forum.pjrc.com/threads/27861-Light-Saber-sound-card-project. It ends with the sound card being a little too big, and then nothing. Obviously the smaller footprint of the prop shield would help here.

And then in November, there was this post by Grimmdus: https://forum.pjrc.com/threads/31349-Teensy-3-2-Lightsaber, and on another group: http://forums.thecustomsabershop.com/showthread.php?18795-Teensy-Lightsaber. It looks like the sound stuff was working (using the audio shield) but then the focus changed to driving the LEDs, and getting into much higher power LEDs than your normal APA102's or WS2812's.

And there was this also in November by Jared Barney: https://trello.com/b/1MbM08rb/long-hilt-teensy-lightsaber-project.

A month ago there was a posting on Reddit: https://www.reddit.com/r/arduino/comments/44hybi/help_with_teensy_sound_installation/

Here is a DIY lightsaber kit that uses an Arm Cortex M3 and various things in the prop shield: http://www.artekit.eu/diy-lightsaber-audio-board/. This isn't a Teensy, but somehow it came up on the google search.

Other than these, it seems a lot of people tend to use off the shelf solutions, either by just taking the toy sabers and harvesting the electronics as it, or using something like the ultrasabers.com soundcard.

Soundbible does have personal use wav/mp3's of the various saber sounds (http://soundbible.com/tags-lightsaber.html), but I suspect a company like PJRC.com needs to be careful of such things.

Soundsnap has more sounds, but I can't see what the rights are to them: http://www.soundsnap.com/tags/light_saber.
 
MichaelM, agree that it was the first thing I thought of looking at the prop shield and have been noodling around with synthasis of effects via the audio library as per a prior post. So far have come up against the fact the speaker size that might conceivably fit in an handle of such a thing doesn't handle the bass that my brain insists is needed.

Now trying to re-design the effects for less THX and more treble. The idea is to allow seamless flowing audio, rather than restricting play to audio clips, though suspecting a SD card full of audio from one of those above linked sites is a far more robust and simpler route to a result.
 
Well one silly thought is to run the speaker wire up your arm, and wear a giant subwoofer on your back. Of course you then probably need the resources of the full sound card with stereo, and not the tiny mono amp on the prop shield. Or maybe something like a nRF2401+ connection to a separate teensy that does the sound (and you have a simple command, like play sound 1).

<edit>
In the end, the prop shield is a compromise to keep the cost/size/power down. It can do many things, but there are things beyond its envelope.
 
Last edited:
Concur that the prop shield beats my prior project light saber project which had to graft together various sub units and pray they didn't fall apart while in use. Though may need to go shopping with onehorse for a power converter to finish it off.

As you note the right solution to the low frequency volume problem is to have a single subwoofer base station that your saber/s cue via RF.
 
Bummer, I was about to move a larger sound (2 minutes, 39 seconds) to the prop shield and it is too large for the flash memory. The mp3 variant is 4.4 megabytes, the ogg variant is 3.3 megabytes. However, when I convert it to RAW, it is 14 megabytes (and 27 megabytes if converted to wav). Too bad we don't (currently) have ogg converters in SerialFlash.

I have other ways to play this sound (audio shield, and some standalone mp3 players), but it would have been nice to keep it on the smaller form factor of the prop shield.
 
I was checking 3.3v power usage with meter, all seemed reasonable at first. But now reading the gyro consumes 20ma ?? (datasheet says 2.7 ma active). I wonder if I fried something jumpering meter inline here and there??? gyro seems to be sending out different values when unit is moved ....

SPI flash was only taking 2.8ma doing erase and 1.5ma doing reads. altimeter 2.5ma, accel/mag 0.26ma

prop shield power consumption


With a second prop shield I re-tested the the power consumption with a DMM. The previous measurements were confirmed and conistent with the datasheet specs. Reading the motion sensors (imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz)) in the loop of the Orientation example only consumes 4 ma on the 3.3v feed. The Vin (5v) draws another 1.4 ma.

With the audio amp running a sine-wave sketch, Vin draws 120 ma to 8-ohm 0.5 watt speaker. If I increase the volume (analogReference(EXTERNAL)), the current goes to 280ma. If I play a .RAW music clip the average draw is 25 ma, and with EXTERNAL grows to 62 ma. LED strips can draw lots more power!

The gyro power anomaly I observed was from running an Arduino sketch to exercise just the gyro. This sketch aggressively configures the gyro, and the gyro draws 24ma (even though the datasheet says 2.7ma active). @onehorse 's prop shield sketch provided in an earlier post also uses this aggressive gyro configuration and subsequently averages around 15ma in the readSensor loop. (The altimeter configuration also draws 20ma.) Paul's gyro configuration is much more power-friendly.
 
Last edited:
Using the current code I got a good mag cal (under 2%) and observed good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation. I can do a video demonstating the effect if the description is unclear.
 
Last edited:
Using the current code I got a good mag cal (under 2%) and observed good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation. I can do a video demonstating the effect if the description is unclear.

I got 2% once - it seems the longer it takes to fill the gaps, the more likely out of bounds data gets counted in the sample, pushing the 2% number higher.

In my YawPitRol sketch built on the Wozzy sketch I noted I saw the two YAW/ROLL axis lock out of sync vertically up and in sync vertically down when using the Fusion data. This was noted with the Processing image of the board by some (until the axis order was corrected) and I found a link on Gimbal lock noted in this post with a video showing it being corrected on a CGI robot.
 
Using the current code I got a good mag cal (under 2%) and observed good performance with the orientation visualiser in Processing, *except* when the board is oriented vertically and rotated slowly around the long axis, the image onscreen rotates erratically. Looks like a numerical instability near that one orientation. I can do a video demonstating the effect if the description is unclear.

Please try this:

https://github.com/Ben-Rheinland/NX...ientationVisualiser/OrientationVisualiser.pde

It's only tested on Windows, but I don't see what could go wrong on Mac/Linux. Hit the h key on your keyboard after bringing the visualizer window into focus to bring up the help.
 
I just recommended the prop-shield-LC to a customer for running neopixels at 5V, with a Teensy 3.2.

While this technically will work fine (if those pinouts work for APA102s they must be fine for neopixels) has anyone tried sticking a neopixel strip on one of the APA102 output pins?

my next adafruit order will surely feature a few neopixel and apa102 strips.....
 
I just recommended the prop-shield-LC to a customer for running neopixels at 5V, with a Teensy 3.2.

While this technically will work fine (if those pinouts work for APA102s they must be fine for neopixels) has anyone tried sticking a neopixel strip on one of the APA102 output pins?

my next adafruit order will surely feature a few neopixel and apa102 strips.....

Well in theory if the conversions were too slow, it could affect the timing of the WS2812B's. I was able to run a 16 LED WS2812B/neopixel ring with no problems off of the APA102 leds (I used the data pin which is connected to pin 11). I suspect you really need to test a much larger strip to be sure of the timing.

I'm sure Pensive knows, but for those that don't, the WS2812B/neopixel only have one data pin, unlike the APA102/dotstar which has separate clock and data pins. This means that the communication must meet some rigid timing windows for the data to be recognized. Some level converters, such as those designed for i2c/spi conversions are too slow to be used WD2812B.
 
As I mentioned back in posting #373, I also have tried using Neopixels, using the Data pin.

Again I only tried it with 7 Neopixels. As Michael mentioned, not sure how timings work, My gut told me that since it looks like the Level converters are setup as I believe output only, that they should be able to go at high speed.

The other things I have not tried yet, is if you can at times still access the flash memory and at other times access the Neopixels. For example if you were doing output to Neopixels and wanted to do a read from the flash memory, you would need to disable the Neopixels (digitalWrite(7, LOW) ) Startup SPI and hopefully be able to access your data, then stop SPI, and enable Neopixels... Again not sure if this would work at all and if so, what if anything would need to be changed in any of the libraries...
 
... output to Neopixels and wanted to do a read from the flash memory, you would need to disable the Neopixels (digitalWrite(7, LOW) ) Startup SPI and hopefully be able to access your data, then stop SPI, and enable Neopixels...

Paul made note of pin 7 toggle and 'active' for APA102's - in the case of APA102's he suggested SPI data would show on the APA's if the pin7 isn't dropped. I wrapped my FastLED function to toggle ON/off that - alternatively you could wrap the SPI calls with the inverse to keep Neopixels from getting confused.
 
Hey Paul...

The new Motion Sensor Calibration Tool (Windows) looks good and works well.
I got my best cal yet: 0.0% gaps, 0.9% Variance, 0.9% Wobble, 0.9% Fit Error
Now I'm going to take my new calibration out for a spin :D
 
Last edited:
Here's yet another version of the calibration tool.
... Windows:
This version adds many GUI improvements, especially on Windows.

Before it was getting data I saw this displayed "?" - hightlighted.
nxp_cal6.PNG

The App might say somewhere what sketch to run this against - like the web page does. At some point should the app show what version of TeensyDuino it was built to run against?

This sketch does EXIT for me - though it seemed to be stalled until I clicked - NONE on the port?

I noticed that the Error % no longer 'only' increases at the end - in fact I got it to drop down to 1.5% after it went up to 2.2%! Then I wrote calibration and all seems well.
 
Paul: Have you got a sketch I can use to test my PropS's flash? It is giving Frank Fits all of a sudden after it worked so well on TeensyTransfer. It runs RawHardwareTest and EraseEverything in SerialFlash, but trying to use CopyFromSerial says it wrote two files but ListFiles won't show them. { I can send it to you at any time if you wanted to explore it }. I've swapped Teensy's already - and DotStar/Talkie audio/IMU still generally function.

I'm thinking something in a sketch to create files and write data to files and then open them and find the data. I didn't see that in the examples - maybe there is one on the Forum? I could try to create a sketch - but would be better to have one known to work looking to confirm hardware function.

<edit> Just found this from sumotoy to work - FIRST TIME ONLY after Format ??? - https://forum.pjrc.com/threads/33594-SerialFlash-filesystem-question?p=99902&viewfull=1#post99902

<edit 2>: Found my Prop Shield flash to be still working - just trying to use GitHub tree in FLUX it seems - and the sumotoy code did catch an issue that should be resolved.
 
Last edited:
I just revised the sketch to improve the fusion rate. I moved the accel and gyro temp fetch into the 2 Hz loop. Now the fusion runs at 780 Hz (with the Teensy at 72 MHz) when the accel is in the active state and 840 Hz when the accel enters low-power mode after 36 seconds of no activity (user configurable). I also corrected the Madgwick fusion call for the actual alignment of the prop shield sensors and changed the Euler angles for the heading reads from 0 to 360 like a compass. I also changed the order of the bias calibrations so the accel, then gyro and lastly mag are calibrated since the two former require no motion and the latter requires figure-eight motion. Everything should be working properly now.

I''m not sure I get all this fusion logic, but @onehorse you seem to run the filter update whether you have new sensor data or not. Paul's sketches only run the filter update if imu.available(), e.g., only if new sensor data is available.

question: is it beneficial/necessary to run filter even without new sensor data?
 
Status
Not open for further replies.
Back
Top