Search results

In case it is helpful, here is another example of reading PPM signals with a timer: https://github.com/Flybrix/flybrix-firmware/blob/master/receiver.cpp#L75

It's also not that hard to just layout the teensy components and buy the bootloader ics pre-programmed from Paul... we've manufactured almost 20k teensy clone flightboards in the last few years at Flybrix.

I finished the first pass on this project today. I think it came out very nicely and it looks and sounds better than the Rolls mimimix 2 it replaced. A couple of lessons learned: - I should have optimized my potentiometer voltage divider circuit for better linearity. I end up using ~90% of...

In case it is helpful, we switched our AHRS filter from an EKF to a UKF at Flybrix with our latest release: https://github.com/Flybrix/flybrix-firmware A complete filter update requires about 2msec of processing time. We're using the filter with an optical flow system but it would be...

I decided I wanted to build a mixer where the signal paths are entirely analog but all of the control is digital so that I could use less expensive trim pots and still get really good linearity and noise performance... I am about to submit the design to PCB.ng for fab but thought I would share...

We're seeing a similar issue with the latest libraries on Teensy 3.2. It appears to be related to the call to "Serial.begin"

Also -- our website still has some really old photos on it because we've been so focused on product development. Here's what the actual boards look like: You can see where we removed a chip in rework. We had included a power switching ic (TPS2111) so that the board would automatically switch...

I've had a lot of fun with the project already! So many intro-to-arduino kits are essentially just blinkies so I'm hoping we will get enough interest for us to produce in higher volumes... The motors are brushed coreless type. The manufacturer is Guangdong Choali Motor Company and the part...

You can also still buy an alpha unit if you're interested @ http://flybrix.com -- I'm happy to create a referral code for any forum members that send me a note!

I'm pleased to share the open-source release of our Flybrix software on GitHub today: https://github.com/Flybrix We started building shields for the Teensy 3.1 about a year ago and made our first run of 100 custom teensy 3.2 clone pcbs with Seeed Studio in December. Here's the schematic for...

Yes -- hoping for a quick reply from Paul but I also know he's busy! It does come down to what the bootloader code does with the pins after it does its bootloading work... I would have to connect the PTA3 pin 3 to some GPIO on the K20 to set things up for tristate so we could use UART, but...

These are Paul's MKL02 chips (IC_MKL02Z32_QFN16 from https://www.pjrc.com/store/ic_mkl02.html) that we purchase preloaded with halfkey -- I'll be sure to add the part number as a comment on the schematic!

I'm looking to add a UART port to my next circuit revision and I have two options: 1. Use K20 pins 37,38,39,40 by rearranging some other connections on my board (moving my i2c bus to I2C1 (55,56) and move a GPIO line to some other open pin) 2. Use K20 pins 22,23,24,25 and share the bus with the...

Is the default "align to edge" or "align to center"? I feel like I'm missing something with the 0x28 setting... Thanks!

I'd like to create synchronized PWM output pulses with fixed offsets. So for example, I'd like to put out PWM pulses on pins 32 and 25 with identical pulse width but offset pulse starting position. Both of these pins are on FTM2. I looked through the teensyduino code and tracked down the parts...

I have completed my benchmarks. With optimized python code on my desktop I can get ~6.5Mbps average transfer rate if I'm willing to accept a variable loop time, or ~2.0Mbps if I want to avoid blocking. I don't think the packet size fed to Serial.write matters very much, other than the overhead...

I implemented binary packet-based communication and a python listener using a dedicated thread. I don't see any dropped packets anymore. I haven't yet figured out if there is an ideal packet length or really pushed too hard to benchmark. I'm happy with this solution. Thanks to everybody for...

I think my ideal behavior would be for the serial write to timeout even faster and drop even more data so that I don't get weird 100ms drops in my teensy code when my pc isn't keeping up. At the same time, I would like to be able to know when the serial write fails -- maybe with an error...

As an intermediate test, I increased the base timeout value to 90: // #define TX_TIMEOUT_MSEC 70 #define TX_TIMEOUT_MSEC 90 This results in more slow loops and fewer dropouts: I guess your usb_serial.c code is pretty explicit in the comments that data will be discarded when the sending...

@ Paul: Here's the baseline result again: I commented lines near 203 in "usb_serial.c" -- when I recompiled I got a warning about an unused variable, so I know the right file got changed: C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\usb_serial.c -o...

Serial.availableForWrite() takes on all values and seems uncorrelated with dropouts. So this is not useful to check... #include <Arduino.h> #include <cstdio> void setup() { Serial.begin(9600); // USB is always 12 Mbit/sec while ( !Serial || millis() < 10000); //wait for user to start...

@defragster: I'm not sure what would be a good stress test for PySerial specifically. This is interesting: http://stackoverflow.com/questions/29557353/how-can-i-improve-pyserial-read-speed

@defragster -- I appreciate that I can "tune" a delay parameter to optimize bandwidth, but it doesn't help me understand why I'm getting corruption/dropouts, and it also doesn't rule out infrequent errors. I'd like to know when Serial.print() is overrunning its buffer if that is indeed the cause...

@stevech - I thought maybe you mean flow control on the serial connection itself. It would definitely be a good idea to move to a fault-tolerant protocol for high speed data transfer if these corruption/dropout problems aren't simple to fix... I guess I am just used to thinking of the usb serial...

Maybe the function Serial.availableForWrite() is useful? I get values from 0-63 that don't seem correlated to the dropouts...

I'm looking over your code and I am not sure I'm following ... are you measuring the time it takes to use send_now()? Why not just print the elapsed micros()? This does suggest the idea of using some sort of feedback-system to dynamically figure out how quickly to send data, but I don't know...

I think the "very long loops" may also be related to serial comm issues. Sending +1 byte of data as we ramp up to 1200usec delay per loop: Sending +20 bytes of data per loop: Note that the dropouts are worse whenever the data rate goes up. If I use "send_now" instead of...

The delayMicroseconds() required to reduce dropouts seems dependent on data writing rate. Also sometimes the loop takes significantly longer to run: #include <Arduino.h> void setup() { Serial.begin(9600); // USB is always 12 Mbit/sec delay(10000); //wait for user to start up serial...

Slowing down the rate that data is fed to Serial.print does seem to replace send_now(). Here I am gradually slowing down the loop and looking for the place where I stop seeing the dropouts (maybe around 200usec of delay?): #include <Arduino.h> void setup() { Serial.begin(9600); // USB is...

I appreciate your help.. I'm not familiar with TYQT -- (this one right? https://github.com/Koromix/ty) -- It may very well turn out to be PySerial that is the problem here. (To address your question on the MPU9250 -- I'm looking at some vibration processes and wanting to capture data quickly...

Here is what the dropouts look like: S 1624 7 S 1625 7 13 S 5724 7 S 5725 7

I modified your code a little bit so that I could use the same python serial reader: #include <Arduino.h> void setup() { Serial.begin(9600); // USB is always 12 Mbit/sec delay(10000); //wait for user to start up serial listener... } elapsedMicros runningms; void loop() { runningms =...

It looks like you removed the calls to "micros()" and put in an elapsedMicros variable -- curious if you think this might be part of the problem? Also, did you try running this without calling send_now() inside the loop?

On the Tx side, I'm just calling "Serial.print()" with a port that I have set up using "Serial.begin(9600)" -- so whatever the defaults are I guess. (Also -- baud rate doesn't matter AFAIK) On the Rx side, I'm using PySerial to set up a port using "serial.Serial(port, timeout=0.01)" and reading...

A little bit of cleanup on code. Also verified that my -O2 pragma was not relevant.

I am returning to my minimal code example because I seem to have some other timing weirdness in my MPU9250 data collection loop. Just to re-establish the problems I am seeing: When sending data without calling the "send_now()" function I get significant data dropouts. I lose almost half of my...

Some statistics on the dropouts using send_now() -- In ~262k transfers I got 180 corruptions. The errors seem random...

@retospect -- I downloaded and ran your code from the other thread without any issues... Getting Port Found Teensy at COM7. Opening port Starting to read Last error: No Error OK: 10000, Error: 0, Error rate 0.0%

I'm using Windows -- it would be great if you could test the code I shared on a mac just to see if this is a windows-specific problem.

The python code is about as simple as I can make it: with (serial): while (true): file.write(serial.readline()) I suppose it is possible that PySerial can't keep up, but I'm not sure how to test this. Any ideas?

Thanks for the tips Paul. I'm getting about 6Mb/sec when I write larger chunks of ~80bytes. The data rate is definitely faster when I let the USB stack manage everything but I get a lot more dropouts. I have now confirmed that I still get occasional drop-outs when I include the send_now()...

When the jump occurs, note that the loop iteration counter is incremented from 597 to 732 -- so my loop is still running and I'm still presumably making calls to println() -- this data seems to just be "lost" somewhere...

Here is an example of the "corruption" I mentioned: S 594 94571 594.000000 027 S 595 94727 595.000000 027 S 596 94886 596.000000 027 S 597 95055 597S 731 231989 731.000000 028 S 732 232171 732.000000 028 S 733 232340 733.000000 028 This snippet shows 3 good messages and then a...

Like many others, I'd like to pull data as quickly as possible from my Teensy 3.2 and want to figure out the best strategy for Serial communication. I know I can get better effective throughput by changing my code -- by sending binary data, being careful not to send redundant info, etc -- but...

I unfortunately did not find this thread before I too built boards without a VBAT connection. My results are essentially identical: lots of USB beeps and no running code until I comment out lines 634-->640 and lines 875-->905 in mk20dx128.c @ Arduino\hardware\teensy\avr\cores\teensy3

I've now built several custom shields for Teensy 3.1 boards for a couple of projects (a pulse oximeter and a LED driver board) and I'm now considering options for combining everything together in a custom single pcb layout. I would ideally like to hang on to the Teensy development environment...