Prop Shield Beta Test

Status
Not open for further replies.
MichaelMeissner said:
Play sounds stored in flash memory. However to do this, you need to be able to download sounds to the flash memory (such as the zmodem thread that went by a few days ago
Click to expand...

USB takes care about tx/rx errors. No need to add an additional protocol.

I posted the "easiest" way to transfer data yesterday. It's not optimal due to other issues, i know.
Currently, i'm writing better a data-transfer-tool which uses RAW_HID. I miss something like this for a long time, and now it's time to finally do it:)
It will allow to use several devices which are connected to the teensy - one is external flash.
 
My prop shield arrived last night and am inspecting it. Lovely.

My first observation is that it would be great if the pin headers and socket were shorter, it seems unnecessary to have 11mm of space between the boards.
I'm considering soldering the header directly to both boards and avoid the socket. Anybody think this is a terrible idea? (I can put the RTC crystal on the top of the Teensy PCB...)
 
Frank B said:
My problem is: I don't know, how.. and i don't want to read tons of docs.
Do you have some consice information ?
Click to expand...

Nope, I only have the PTP and MTP specs from www.usb.org. Well, I also bought a Sandisk MP3 player which implements MTP (intended for reverse engineering), but apparently it has a buggy implementation that Linux rejects, but Windows allows. Truth is, I'm still figuring this protocol out too, and the MTP spec leaves a lot to be desired. :(
 
>...soldering the header directly to both boards...
I did that with the first audio shield. It has the obvious consequence that you won't be re-using that Teensy again for other purposes, at least not without a lot of work. If you already know that your particular Prop Shield has no hardware problems, and you'll never want to access the inner surface or use it or the Teensy standalone or mount it differently, then go ahead.
 
PaulStoffregen said:
Nope, I only have the PTP and MTP specs from www.usb.org. Well, I also bought a Sandisk MP3 player which implements MTP (intended for reverse engineering), but apparently it has a buggy implementation that Linux rejects, but Windows allows. Truth is, I'm still figuring this protocol out too, and the MTP spec leaves a lot to be desired. :(
Click to expand...

I worry that MTP isn't widely supported.

I know that there has been some effort towards support of Mass Storage Device class and understand that there are some issues, especially surrounding the teensy and host arbitrating read and write. It seems, though, for a majority of applications that there will only be a single writer (i.e. the host loads up files on the teensy or the teensy writes some log files).

It makes the most sense to me to have a Teensy MSD library make the sketch decide if it's a writer (i.e. it can only open files for write and not read) or a reader (it can only open files for read and not write). When the sketch is a writer, the host sees a write locked device. When the sketch is a reader, it waits until the host has unmounted the device before reading safely.

I'd love to be able to plug in my teensy, drag a file or two to it and then unmount it and reboot on a battery and have the teensy then have access to the files.
 
FWIW, I wanted to connect my Samsung Galaxy S5 to my Linux computer recently via USB. The last time I had connected a phone as a remote disk, it was when I had my Samsung Galaxy S2, which supported USB mass storage. However, the S5 no longer supports USB mass storage, and only supports MTP. I discovered that even after I loaded the simple-mtpfs program on my Fedora 22 system, it no longer auto mounts, and I had to explicitly use simple-mtpfs to mount things by hand. Progress I guess (more, it reminds me of what I needed to do 5+ years ago).

Anyway, you might look at what the LInux support looks like (https://github.com/phatina/simple-mtpfs), but not it is licensed by the FSF, so be sure that you are comfortable with the copyright.
 
If Mahony is open source, I'd like to package it up into a similar library with the same API.
Click to expand...

Madgwick and Mahony algorithms are open source. Frank listed the references and I have been using them (re-written for Arduino and readability) that way for two years.
 
I think i have my result faster with my RAW_HID idea.
It can be used from commandline, from a script - and you can drag'n drop files to it if you place it on the desktop (as with every commandline tool)

More than i need :)
( i'll publish it on GitHub in a few days - if someone is interested and has additional ideas: mail me)
 
PaulStoffregen said:
[...] NXPMotionSense library [...] I'd like to ask everyone to please give it a try.
Click to expand...

Been using code like this make a crude realtime visualization in the serial monitor.

Code: 
    int16_t x = 10.0f * logf(10.0f * (mag[0] < 1.0f ? 1.0f : mag[0]));
    Serial.println(
      "999999999 888888888 777777777 66666666 555555555 "
      "444444444 333333333 222222222 111111111 000000000" + (100 - x));

Looks promising. Once I got an initialization error from one of the sensors and needed to power cycle the board. If it happens again, I'll make note of which device it was.
 
Last edited:
Yes, i use code from Pauls example which can be compiled on Linus, Windows, and MAC.

(at the moment i have problems with argp.h which seems not to be available for mingw - i use a Lubuntu virtual machine to compile.
i think i have remove that from my already written code and work with getopt instead..and i hope that it works :) )
 
My Adafruit parts arrived :D Now time to assemble.

Now for some dumb questions ;) Are most people installing with prop shield above or below the T3.2? Are you using the 14x1 sockets and headers. I assume you would still need to connect up the pins on the A14/Dac row as well.
Thanks
 
Ok, here's the first beta test for the magnetic calibration gui:

Linux 64 bit: (32 bit coming later...)
http://www.pjrc.com/teensy/beta/imuread/gui.linux64

Macintosh:
http://www.pjrc.com/teensy/beta/imuread/gui.mac.zip

Windows
http://www.pjrc.com/teensy/beta/imuread/gui.exe

To use this, first program your board with the NXPMotionSense CalibrateMagnetometer example. Open the serial monitor to check that it's rapidly printing raw data (9 comma separated fields).

Then close the serial monitor, and run this program. Use the Port menu to select the serial port.

As you move the prop shield around, you should see red dot appear as magnetic calibration data is logged. If things go well, the data should form a sphere that rotates perfectly centered. The "hard iron" cal is how well the sphere turns on its center, and the "soft iron" is how spherical it looks.

This thing has a LOT of rough edges still. The GUI is pretty spartan, and there's no visual feedback about many little things. Good GUIs take a lot of work. At this very early stage, I'm mainly just looking to find out if it works at all? If it does run, how much CPU load does it put on your machine? Is your video card's GPU able to keep up?
 
Also, please let me know if are you able to resize the window? If you can, does the graphic part grow as you change the window size?
 
The GUI behaves as you describe. Visually the red-dot sphere rotates around it's center. I'm on Windows 7 Professional SP1 and i can _not_ resize the window.
Also, while my teensy/prop shield are not moving, the sphere slowly rotates. is this normal?
The dot's are more or less all on the sphere surface, with the exception of maybe 6-8 points after swinging the teensy/shield to cover the whole sphere surface for about 15 seconds.
The "File" -> "Send Calibration" option is greyed out. So I actually can't calibrate the compass.
The "Communication" and "Gyroscope" areas are empty boxes in the window.

If you wish I can add screenshots

-Ben

Edit: After letting the GUI sit there connected to the teensy/prop for a minute the "Send Calibration" option is no longer greyed out. I sent the cal and restarted by deselceting and selecting the com port. Visually I think the sphere looks a bit better now, bit this may be expectation bias.
 
Last edited:
Got the following message when clicking on the menus the first launch on OS X:
Screen Shot 2016-03-15 at 5.11.01 PM.png
 
I'm assuming the NXPMotionSense CalibrateMagnetometer example is from your Github repo. In which case there is an issue with the update() method int the NXPMotionSense.cpp where you don't set newdata=1 for any new data. So nothing is outputted.

EG
Code: 
void NXPMotionSense::update()
{
	static elapsedMillis msec;
	int32_t alt;

	if (FXOS8700_read(accel_mag_raw)) { // accel + mag
		//Serial.println("accel+mag");
	}
	if (MPL3115_read(&alt, &temperature_raw)) { // alt
		//Serial.println("alt");
	}
	if (FXAS21002_read(gyro_raw)) {  // gyro
		//Serial.println("gyro");
		newdata = 1;
	}
}

Should be

Code: 
void NXPMotionSense::update()
{
	static elapsedMillis msec;
	int32_t alt;

	if (FXOS8700_read(accel_mag_raw)) { // accel + mag
		//Serial.println("accel+mag");
		newdata = 1;
	}
	if (MPL3115_read(&alt, &temperature_raw)) { // alt
		//Serial.println("alt");
		newdata = 1;
	}
	if (FXAS21002_read(gyro_raw)) {  // gyro
		//Serial.println("gyro");
		newdata = 1;
	}
}
 
I attached the boards and I am running the Gui test on Windows 10. I do see the read dots, and not resize the window.

Kurt
 
KurtE said:
Are most people installing with prop shield above or below the T3.2? Are you using the 14x1 sockets and headers. I assume you would still need to connect up the pins on the A14/Dac row as well. Thanks
Click to expand...

For me - I debated for some hours . . . and then I under pinned a T_3.2 and did top header on the Prop board. I put pins across the T_3.2 power/DAC end too (not included). I'm okay with it working like this. I also pulled 9 short header pins and changed for 9 long header pins to attach the onehorse Serial2 ESP8266 unit below that since I had top headers on that ESP unit it works - but stands a gross 1 1/4 inches tall . Avoided all the active Prop pins on that end.

To get this I cut and un-soldered some header pins before (the T_3.2 was pinned under the ESP8266) - the Prop board is probably stuck with header on top - the ESP could still be adjusted again.
 
defragster said:
For me - I debated for some hours . . . and then I under pinned a T_3.2 and did top header on the Prop board.
Click to expand...

Same here, but I didn't connect the 5 pins on the short side. For the Prop shield only the A14/DAC pin is needed, and I haven't yet tried out the speaker. I have ordered female headers like the ones that came with the Prop Shield and will use these on the short side once they arrive.
If I really couldn't wait to try the speaker a straight bent paperclip would be my solution for the DAC connection. But I'm playing it safe since it would be a shame if i wrecked my prop shield. It's currently resting on it's ESD-safe throne ;)
 
Status
Not open for further replies.
Back
Top