Prop Shield Beta Test

Status
Not open for further replies.
I'm going to try some ideas to handle these cases much better. Ideally, when the gaps are under 20%, it should become possible to automatically purge this bad data, and most of the lower quality data causing the variance error. But rejecting bad data is tricky

Tricky was my expectation. That why I went as far as "suggest starting a new calibration session". If you did the colorization of such odd 'solar flare' type data - and show the percentage of data that is being used to alter the current state of the 'calibration update'. Maybe when 'Send Calibration' is selected you could pop up a dialog: " xx% of the data in this sample session appears out of bounds - Yes to save, no to start a new session "

This time I neared the magnet on purpose - the other day it was inadvertent because I was staring at the screen I wasn't watching my hand - but then I also knew I got near something drastic - so I looked to see what was around me.

BTW: with it lying on my desk I pushed my Cortex powered 'BAND' around it and nothing odd happened this time.

ALSO: to multitask here - Frank updated his TeensyTransfer and it compiles for me - he fixed the one long name garbage - then I found another oddity I told him about.
 
ALSO: to multitask here - Frank updated his TeensyTransfer and it compiles for me - he fixed the one long name garbage - then I found another oddity I told him about.

Yup, it's a little bug in SerialFlash. I created a pullrequest for fix, already.
 
Frank - will free'd flash automatically ERASE and recycle? Having PC write access to Teensy flash it cool.

The SPIFFS on ESP8266 allows that - they implemented the SPI Flash File System and on a 4MB Flash, 1MB is code space and the other 3MB can be a SPIFFS device that takes OTA/FTP or Sketch FS operations, though coming in OTA/FTP requires a restart to see it.

Yup, it's a little bug in SerialFlash. I created a pullrequest for fix, already.
Good work again Frank, hopefully it'll make it in 1.28? This is too odd:

C:\tCode\libraries\TeensyTransfer\extras>dir > who2
C:\tCode\libraries\TeensyTransfer\extras>teensytransfer.exe -w who2
C:\tCode\libraries\TeensyTransfer\extras>teensytransfer.exe -l
874 foo.txt
12612 Ttrans.zip
623 README.md
1072 LICENSE
634 foo2☻z
688 foo2foofoofoo
792 who2♥↑
C:\tCode\libraries\TeensyTransfer\extras>teensytransfer.exe -e who2
teensytransfer: File not found
 
Frank - will free'd flash automatically ERASE and recycle?
No, the library does'nt do this - but you can erase the whole chip. May be i add an option for this..
This is too odd:

This happens only with filename with length of 15, 31, 47, or 63 bytes. So not a really big problem.
It happend to be so obvious, because TeensyTransfer shortens too long filesnames to 63 (64 incl trailing #0)

Best is, you erase the whole chip,and apply the patches to the lib (or use short filenames)
 
Last edited:
FrankB - I went to your SerialFlash [patch_3] fork and then built 'teensytransferflash' - from a write of 'who3' lists as "who3♥E". This is a short name (ending in a number) - not a long name issue?

Multiple libraries were found for "SerialFlash.h"
Used: C:\tCode\libraries\SerialFlash

// line 242 of SerialFlashDirectory.cpp reads: addr += sizeof(buf);
 
Last edited:
Might be the other issue i fixed..
Did you apply both patches to SerolFlash, and erased the chip ?

If yes, can you somehow post an example that i can try myself ?
Perhaps a batchfile ?

maybe there is a third bug somewhere..

Edit: Maybe its better to open a new thread

Edit: Pls. restart arduino after patching, to be sure..


EDIT: Ok, the third bug was mine :)
 
Last edited:
Looks good Paul - my APA102'2 should be here in next hours. I saw TODO on current/LED count - I have a 30 LED Dotstar strip - how many LED's can I expect to work from a T_3.2 : five? [3*20ma * 5 = 300ma]

Would it make sense to put the MAJOR detail on the lowcost page and the NXP specific details only on the http://www.pjrc.com/store/prop_shield.html page and a LINK to the lowcost for the rest?

At $8.40 I assume more of those will be sold. Those opting for the wit MOTION version could find those added details, and that page could grow and grow - and those without would have just the AMP/FLASH/LED info in front of them which is quite a lot for the price - but doesn't seem apparent with how empty the lowcost page is right now.
 
"This shield features 10DOF motion sensors, 2 watt audio amp, high speed 5V buffers for driving APA102 LEDs, and an 8 Mbyte flash memory for images, sound clips, or data logging."
I gather the altimeter/pressure sensor is the 10th DOF ? It also has a temperature sensor, if that matters to anyone. Nice looking page anyway.
 
Hi Paul:
A few typos etc. on the prop shield page.
http://www.pjrc.com/store/prop_shield.html

> The Prop Shield is meant interactive light
There's something missing here. This same error occurs on the low-cost Prop shield page.

> the Arduino Serial Monitor will show you computed Header
Heading?

> As you turn the board in each direct
direction

> The Prop Shield has 5V buffers meant to sending data
send

> to prevent other SPI chips from intefering
interfering

Pete
 
the audio library will create a 1.2Vp-p signal at the DAC pin
Paul: perhaps point out that the DAC pin on the T3.2 must be wired to the DAC pin on the Prop shield since they aren't connected by the 14-pin headers?

Pete
 
AdaFruit box got here - I can confirm the Prop Shield I got runs the sample code shown here.

I can also pass along a tip, that swapping the Data and Clock line will allow some LED's to light - but in a way that is more disturbing than programmatically satisfying. Typing this reminded me someone already posted that the Prop Shield ordering of GND/CLK/DATA/5V != DotStar's GND/DATA/CLK/5V. And additionally that pulling the 5V line alone from the plug does not stop the DotStar from keeping some of those LED's lit, i.e. it must find some helpful voltage from said Clock and Data lines, made me think that flipping off my USB power switch might someday keep me from disaster, so far the Teensy has been robust enough tolerate my treating voltage like a compiler error - just edit it and try again without rebooting or unplugging anything.

I'll copy all the non-motion info soon, probably sometime next week.
Okay, I thought you were doing that on purpose to prevent duplication where one might not match the other someday without two updates.
 
@PaulStoffregen: So far I didn't see any problems with my board, but some indirect issue on OSX with the IMU GUI, which is used to calibrate.
Even after successful calibration, the File->Send Calibration is greyed out.

Update: I figured out this is due to the high error. Another error after calibration is: The values will always increase / the Processing demo will always keep rotating slowly.

Update2: MacBook Pro owners: Keep your Prop Shield at least 2-3 meters away from your MacBook. Either due to the aluminum unibody or magnets (or maybe interference) the calibration fails!

Bildschirmfoto 2016-03-29 um 09.33.12.jpg
 
Last edited:
I cannot get stable data from filter.update()

I got my APA102's running - put R/G/B on the x/y/z axis values of the three sensors individually and that was good and stable - from within the CalibrateSensors sketch. I wrote a Min/Max function to track the values seen on each sensor so I could use the map() function to scale for my 30 LED strip.

Then I copied at Wozzy's prior post#375 sketch and tried that and got no lit LED's - changing the NUM_LEDS to match my 30 strip instead of his 144, I PM'd him about that in case his scaling included his 144.

I picked up the use of the filter.update(gx, gy, gz, ax, ay, az, mx, my, mz); and that seemed like a good step.

I just get Roll/Pitch/Yaw in a random display of R-G-B - very twinkly! When I check my Min/Max values that start at 1000,-1000 they are quickly set to full range values.
MinMax x, y, z __ val =0 / 359 __ val =-179 / 179 __ val =-89 / 89

This can only happen if the full range of values are seen - and I get that without moving my Prop Shield? When I start without moving the PropShield on the other three sensors I get an expected similar effect - but that is because Min/Max are changed to the power up value plus jitter until movement expands the Min/Max.

Writing that I wondered if I had an OLD libraries\NXPMotionSense - but I was current and a Sync'd copy does the same with an IDE restart. Is there something I failed to copy from Wozzy's simple example that would explain why I cannot get stable data from filter.update()? And does Wozzy's example work for others on a 30 LED strip?

My code is this: View attachment DOT_CalibrateSensors.ino

I started with the Prop_STORE sketch - just calling it loop2() and setup2() above the CalibrateSensors code, then call as needed. As noted for any one sensor x,y,z the same code gives stable results - except I could never isolate my movement to a single LED R.G.B scrolling perfectly to tell me which axis was which - I expected Y/P/R from Wozzy to do that?

My MAG calibration got to 2% and was stable -does that say all three sensors are working together or MAG only?
 
I cannot get stable data from filter.update()
I copied at Wozzy's prior post#375 sketch and tried that and got no lit LED's

Defragster,
I'm away from my workbench right now, but earlier, I did cut and paste the code from the forum post#375 into my Arduino IDE just to verify that there were no errors there.
I'm running my Teensy 3.1 at 120Mhz. I did need to play with the FastLED DATA_RATE_MHZ(12) value to get stable results.
I'm running Arduino1.6.8 and Teensyduino 1.28B1 , Stock FastLED3.1 and the latest (as of yesterday) NXPMotionSense library.
Also interestiing that My APA102 strip had the wires in the same order as the Prop Shield Gnd-Clk-Data-5V.
Also, the LEDs on my strip are in BGR order and not RGB order.
 
Last edited:
AdaFruit box got here - I can confirm the Prop Shield I got runs the sample code shown here.
Typing this reminded me someone already posted that the Prop Shield ordering of GND/CLK/DATA/5V != DotStar's GND/DATA/CLK/5V.
Yep I mentioned that earlier.

Also I found in my case the connectors were connected to the output side of the strip and not the input. So was not getting much of anything, until I moved connectors to other side.

I just tried Wozzy's sample program for the APA102s... It works :D, but needed to edit the program to make it work correctly when NUM_LEDS != 144.

In particular where pos was calculated. It was:
Code:
pos =  abs((filter.getPitch() * 144 / 180) - 72);

currently I have it as:
Code:
pos =  abs((filter.getPitch() * NUM_LEDS / 180) - (NUM_LEDS/2));

Kurt
 
Thanks Kurt - that was my speculation to Wozzy in PM - the scaling factors he derived had the NUM_LEDS factored in as a constant not the #define as you did. I was willing to wait on that - except it is clear I am getting FUNNY numbers from my filter.update() given that my Min/Max watcher sees near the full range of values while the Prop Shield is unmoved in the first 2000 reads. I get beautiful response and operation on x,y,z from the other three sets of sensors.

Hoping Paul can make it through my post - at least to say if the MAG Calibration uses only MAG or all three sensors to confirm if .update() effectively should work - as that reading why my code breaks AFAIK.

Kurt - can you try my posted code on your system? <edit>: call to loop2() at line 138 is the one using Y/R/P - swap the commented loop2() call line to see other sensors work

<edit> :: you made the right edit to the Wozzy code - it works the LED's with the edited "pos =" line. The other problem must be mine ???
 
Last edited:
Kurt - can you try my posted code on your system? <edit>: call to loop2() at line 138 is the one using Y/R/P - swap the commented loop2() call line to see other sensors work
<edit> :: you made the right edit to the Wozzy code - it works the LED's with the edited "pos =" line. The other problem must be mine ???
It runs, not sure what it is supposed to do?
 
Status
Not open for further replies.
Back
Top