Search results

Sorry, I am not familiar with that supplier. All PCB manufacturers should offer a choice of surface finish, such as HASL, ENIG, silver or tin.

I'll just add that we've had good results making our own T3.2 and T3.6 custom designs and other boards with assembly at PCBWay. They have done a good job finding my errors, and were quite patient going back and forth as I solve them. To save on assembly cost for samples we typically have them do...

The root cause of the failure was found to be the "unknown descriptor" above. The descriptor is recognized as 0x24 = Audio CS_INTERFACE but the subtype is 0x00. Valid types are 1, 2, 3 or 4, and a couple of special cases for Yamaha and Roland. We added a case to the subtype parser in midi.cpp to...

There's also an "unknow descriptor" on the USB Device View screen shot above, 0x24. Apparently its typically used on cell phones for mic and speaker select.

We have a USB MIDI device called OXI One that is failing on the USB host. We used a Teensy 3.6 with a powered USB hub, as the device needs 500mA and is USB powered. To eliminate our code, we used the InputFucntions example to test it and captured some debug output. We also tested with a...

Do we know, does the same USB client library run on other Teensy's with the latest version of Teensyduino? That is, can we get whatever was fixed in the Teensy 4 USB client code to run on Teensy 3.6 or 3.2?

Hi, just getting started with FlexCAN on T3.6. We've got it sending and receiving, but are unclear if there is a way to simply detect that a CAN device is attached to our Teensy CAN interface? Bonus if there's a callback for that :D Our Teensy has a lot to do besides servicing the CAN...

Subscribed ;) We have customers complaining that our 3.2 based widget doesn't work with the iConnectivity MIDI routers USB host and would like to find a solution.

There are some tiny RGB LEDs out there now that could make for a nice 2nd LED. http://www.newstar-ledstrip.com/products-195.html

New circuit boards from our pilot run, in matt black to minimize light scatter in the enclosure. We found USB jacks with black interiors for even more sexyness :o

Its looking more complete now, with the anodized extruded aluminum enclosure and light pipes.

Thank you! The NDLR is T3.2.

Very cool, would love to see a video of it in action!

Conductive Labs have made a super deluxe high performance MIDI router using Teensy 3.6, called MRCC - MIDI Router Control Center. The MIDI router features many traditional MIDI 5 pin inputs and outputs and modern 3.5MM jacks, plus 4 USB host ports for USB MIDI class compliant devices, or a...

Yes, smoke test worked and we could use a keyboard plugged into the hub after toggling it back on. Thank you for the help!

Thank you Paul! The hub controller is a MaxLinear XR22414CV48TR-F. Its a stand-alone hub designed for embedded applications, with pre-programmed Vendor and Product IDs. Very convenient! The only downside so far is availability. Its got an integrated automatic power-up reset and an external...

Shoot, sorry I think I put this in the wrong area. Maybe admin can move it to Technical support.

Hello, I'm interested in creating a pseudo "standy-by" mode on our T3.6 based widget, which would include turning off the USB Host power. On our widget, PTE6 is connected to a (self powered) USB hub chip's VBUS_Sense pin, so it won't power up until Teensy runs USBhost_T36. This works great...

We use Teensy as a basis for commercial products and have implemented T3.2 and T3.6 (laying it out now). What a wonderful way to accelerate development, and we really appreciate the hard work that has gone into the software base and contributions from the extended team of users. We are happy to...

That's the schematic for the Teensy 3.6, not the ref board. The big difference is the pins on the K66 are numbered for BGA and not the LQFP that's on the ref board. Ref board uses MKL04 instead of MKL02 that's on the T3.6. Not sure what other differences there are, but that's what we'll have to...

I have found the answer... its on the MKL02 page Also, an enlightening post in the archive by HWGuy. https://forum.pjrc.com/archive/index.php/t-39801.html HWGuy 12-10-2016, 08:21 PM Here Paul recommends 20pF load capacitors for a 18pF crystal (Teensy 3.1)...

Another Teensy 3.6 reference board question. The datasheet for the K66 does not specify crystal load capacitance in the table (in section 3.3.3). There's a footnote (1) that says internal capacitance is 20pf. And footnote (3) says you can use internal caps to achieve proper capacitance, which I...

Hi Paul, sorry we've been distracted with a hardware production issue but I wanted to let you know we are still thinking about this. We've primarily been testing with the test code from msg #1 since we removed all of the serial writes from our codebase so can't replicate the issue reliably with...

I'll give it a shot Paul, but unfortunately we've been readily reproducing the issue with the new code. I did the "remove a semicolon" test and verified I was building with the new bits. Last week I couldn't reproduce the issue. I was messing with the code trying to push more bits with a BPM of...

Yes, its looking good Paul! I think none of my tests have been valid for one reason or another. For instance, on our codebase, we've already removed all of the print statements so there was no serial output. So it wouldn't have failed. I'm also following defragster's advice to test the build of...

I tried changing build options to LTO to force recompile of libraries but it didn't help. We also tried putting a serial.print in the .c file but that doesn't work. So we've built our full codebase with the new usb_midi.c and have that running on two systems and >9000 seconds without a problem...

The first system failed too, at about 7800 secs. As before, opening the serial monitor recovered it to a steady 120BPM.

I have one still running at about 4500 secs, the other croaked at about 2700 secs :(. I'm going to reboot the system and restart the test.

I've got it running, I'll let you know in a bit if I see anything interesting!

Happy to have given you a real challenge :D Have fun on that burning man project, I'm sure it must me interesting! In the meantime, we have a workaround for our Teensy powered widget; we just changed the default MIDI ports from "all" to the 5 pin DINs so customers won't get into wonky state...

I finally got a fail again, nothing to speak of wrt the GPU or other utilization. So I did the reboot test, Teensy stayed running and it recovered the BPM indicating that restarting the Windows side at least temporarily clears the issue. Update: After reboot, as expected if failed again in...

Defragster - wrt to the monitoring app, it hasn't mattered if the app is running or not, or which app is used to monitor. In other words, for MIDI it doesn't seem to matter if we "consume" the data in Windows. Besides MIDIClock, we've used MIDI-OX and various Windows MIDI instruments such as...

Very possible its Windows. As mentioned above, no problem when using iPad as host.

Or maybe MS is hiding their background update tasks. Winvir shows .165 and I don't have any new updates this week showing up in my Updates history, I might force an update and see if it changes anything. Am I correct in thinking this is the driver to watch? Windows audio driver version...

Something that might help, is once it gets into that condition, if you open a serial terminal it will typically recover for a short time (10 minutes maybe?). it might give you a chance to see it fail again without the long wait.

Hi Paul, I've tried a bunch of experiments to try to get it to fail faster. Its been a futile exercise, it seems pushing it harder is making it run longer. For instance, cranking up the BPM to 650 and putting a serial print between each MIDI clock tick and it ran for hours. Now I'm just crossing...

Thanks again Paul, appreciate your time and effort. I'll try some experiments to see if I can get it to fail faster. I'm thinking that just shoving more data into the serial interface might do it, I'll let you know.

Added back serial.begin, and compiled with MIDIx4 + serial, no serial prints. It ran for 3 hours before getting into the condition. That's much longer than the 45 min to hour it normally takes to fail. Opening a serial terminal did not restore performance, and there was no data in the serial...

Another observation... When we remove all serial initialization and prints, and build with MIDIx4 without serial, we never get into the bad condition. Its run for some hours that way. Next I'll try putting the serial init back in, but not serial prints, add the 'while (usbMIDI.read()) ' and...

In our system's code we call it in the main loop without the While. After seeing your message we decided to try it with the While, and didn't notice any change in general behavior. That is, we do consume incoming MIDI messages, and with the While it was still working.

Ah yes, good catch. I'll add the following as we have it our system's code and test again.

A new and interesting observation Paul, maybe this will help with diagnosis... After Teensy goes into the "condition", I opened a serial terminal and Teensy recovered! It started playing notes and the clock stabilized. It ran this way for a while then went back into the condition, at which...

I should add, that running the above sample code, just plug Teensy into USB on Windows and start the monitoring program. It immediately starts sending clock and notes. Also, I'm going to try this now, but you shouldn't have to use any program to monitor clock if you load a soft-synth and listen...

This MIDI tool for Linux looks useful. You can select what type of MIDI messages to monitor. However, for this exercise its useful to have a graph. https://sourceforge.net/projects/kmidimon/ Discovered at http://tedfelix.com/linux/linux-midi.html

Thanks Paul! The two tools we use most are MIDI-OX (http://www.midiox.com/zip/midioxse.exe) for Windows and MIDIClock (http://midiclock.com/wp-content/uploads/2014/04/midiclock4.01.zip) for Windows. It would be interesting to see if this happens on Linux. Maybe someone can recommend a MIDI...

Issue: When connected to Win10 PC USB, sending MIDI clock (usbMIDI.sendRealTime) and MIDI notes, after about an hour the Teensy becomes very sluggish, eventually MIDI notes stop sending but clock still sends, though timing is erratic. This is fairly readily reproducible on our 3 Windows 10 PCs...

For future reference, from other threads... the priorities are as follows: All the interrupts default to priority 128 USB defaults to 112 The hardware serial ports default to 64 systick defaults to 0

Thanks for the reply Paul. Unfortunately we designed a circuit that relied on high impedance on PTE0. We tried setting PTE0 to Input, but it doesn't seem to fix the issue so we will continue troubleshooting at the hardware end and probably change the circuit design.

Hello, having some trouble using the functions to set I/O registers as described here: https://www.pjrc.com/teensy/pins.html Using the Arduino IDE, PORTC and DDRC are recognized, but PORTE and DDRE are not. We are not defining either PORTC or PORTE. The goal is to tri-state PTE0 (Teensy pin...

Thank you for the heads-up on that Paul. I was hopeful the answer would be similar to the previous poster, "Odds are good it will work." but no support... Do you plan to be at the Dorkbot meeting on Monday? Maybe we'll see you there. We'd like to thank you in person for the great work you've...