Search results

It makes sense on any teensy, hardware support isn't a necessity for a PTP implementation. Hardware support only changes the layer at which the NIC packet timestamping occurs, and hence the quality of syncronisation.

Looking great, I didn't see any reference to ethernet MAC pins but I assume they're accounted for. Hopefully also the ability to access 1 or more 1588 related timers? (If this SKU has a hardware timestamping block that is.) Edit: Quick look in the reference manual looks positive for 1588...

The minimum - a 1k resistor in series (therefore limiting the current through the internal clamping diodes). Downside: Less S&H charge current for the ADC so might increase the variance in readings. Epyon's circuit makes an assumption - the source of your analog signal doesn't have a very low...

Logical; for sure. Good behavior; certainly not. Once 0 has been set once, it seems any positive integers after this point don't work. This would be ok if documented but it's not in the GitHub source or the PJRC page.

Figured it out - passing a frequency of 0 creates some kind of unrecoverable fault. Coercing to 1 or higher fixes it.

Code running on Teensy 3.6: https://gist.github.com/macaba/33813b083b226fead09bfc127f83d7a2 It's so simple, I'm sure I'm missing something obvious... The sketch as-is won't output any tone (but the Serial output shows valid frequency numbers). If you uncomment line 17 and comment out line 16...

This was interesting reading: https://www.degruyter.com/downloadpdf/j/ipc.2014.19.issue-2-3/ipc-2015-0006/ipc-2015-0006.pdf It would seem to suggest (for the DLP2000) that each data line of the DDR interface corresponds to a sector of 30 horizontal lines. So as a test; I may try a 80MHz clock...

Hello! Interesting timing for your post - I'm looking to control a DMD (DLP2000) for some optoelectronics research. What I've determined so far: The DLP2000 is driven from the TI ASIC with a DDR interface with an allowable clock range of 60 to 80 MHz at an IO level of 1.65V. It's possible...

A friend and I built his 747 cockpit from real parts. I've built about 12 Teensy boards so far to interface various panels and motors to the simulation software (Aerowinx PSX). In a nutshell - Teensy is wonderful for flight sims (though we've completely avoided using USB and use Ethernet instead...

I recently had a similar issue on a PCB that contained plenty of parts designed to reduce noise (linear regulators with good rejection in the expected power supply noise region feeding my analog circuitry, ferrites & LCL filters). It turned out to be the ground lead on the oscilloscope probe...

This is really great stuff, I've subscribed to this thread.

FYI for anyone who comes across this thread - I wanted to use USB during development for debug output, so I used this macro to eliminate the interrupt jitter: NVIC_SET_PRIORITY(IRQ_USBOTG, 200);

I think this makes sense given the noise problem & the target market, and would say that alongside the release of a Cortex M7 it would make sense for the community (or Paul, time permitting) to release a small reference board in the same form factor as the Teensy (perhaps piggybacking the DIO...

As practical confirmation of the theory - when looking on the oscilloscope with infinite persistence turned on (150kHz PDB rate), the difference between 'USB Type: Serial' and 'USB Type: No USB' on the ADC1 interrupt jitter is clear. With USB: Without USB: My design uses a WIZ850io for...

A small update: I've been testing the top end speed using the non-DMA sketch above. I can get upto 266kHz over 4 channels which is brilliant. Things to be wary of during testing - sometimes you can go slightly higher than 266kHz but in actual fact, the ADC0 data is lost (without triggering a...

Thank you! Kudos from me. I'll give this a go, your explanation is fantastic. I've got a low impedance driving my ADC inputs so I should be able to set averaging to 1 to give me much more timing headroom between ADC conversion time and my desired PDB sample rate (about 100kHz for 4 channels...

Hi all, I've got my Teensy 3.6 acquiring from 2 channels, using the 2 ADCs, continuously using Pedvide's ADC library. (with the practical settings I've picked, I get adc0 interrupts at a jitter-free 156kHz [12-bit, averaging:4, No USB mode]) What's the ideal way to get continuous acquisition...

I don't think it's too bad - take Paul's barebones code, add UDP and PTP support and you've got the bare essentials for messaging and synchronization. (In the typical application for PTP - I don't see TCP as essential in the 1st version, you can do application-layer request-response messaging...

A cursory glance at the AES67 specification indicates the requirement for a PTP stack - so the Teensy 3.6 with native ethernet would be recommended instead of wiz850io. (Teensy 3.6 has hardware timestamping support which is the crucial hardware feature required for a good PTP implementation)...

Perfect, I'll keep releasing real-time oriented objects. When I've used them a lot and they're confirmed to be bug free, I'll look at doing pull requests. I've seen there is a F32 fork of the audio library for floats but it needed a bit of work before coming 'official' - can I help? I'd like...

Add this as a private variable to your class: audio_block_t *inputQueueArray_i16[2]; Edit: Looking at the float fork of AudioConnection, I'm not sure if my suggestion is helpful. It would be how you'd fix it in the standard library.

I think there is a case of confused terminology here - A Noise Gate isn't a modular synthesis thing, it's an industry standard live audio processing thing. Example device: http://www.drawmer.com/company.php#201 I guess it comes down to whether you're just aiming the audio library at synthesis...

It's not a direct comparison as Envelope generator is externally triggered (using noteOn()) whereas a Gate is signal triggered (using threshold(n) to set trigger level). Envelope = for synthesis, Gate = for audio processing. To misuse the envelope as a gate would require a bit of glue logic in...

It's common in live performance to use gates on things like drum kits to clean up the sound from the mic on each drum. (https://en.wikipedia.org/wiki/Noise_gate) From an audio waveform perspective, it looks a little like this: Top trace is before gate, bottom is after gate. Gates tend to...

I've got this new object: Which replaces all this spaghetti (not all wires shown - it got difficult to see where I had wired to): The CPU load scales with inputs, so if only half the inputs are used, the object uses half the CPU load. [This is done by checking the result of...

And the removal of 140 audio connections & the lower complexity of the diagram leading to less bugs. Would you write messy C code? Paul; please don't disincentivise wanting to make a contribution, this is just the start of a few planned audio objects.

Thank you Paul, I got it working and added it to the Audio System Design Tool too (on my fork). Brief testing shows it works, I'll be able to do further testing once I've got a TDM board. It means I was able to simplify a design with 80(!) 4-channel mixer objects to this: Edit: Spoke too...

Is there any audio library developer documentation out there? I'm making a 'AudioMixerCrosspoint16' object that will mix 16 input signals to 16 output buses. I've used AudioMixer4 as my template but that only deals with 1 output stream so I'm unsure how to add more output streams. Edit: My...

Of course. This now seems entirely obvious. Consider me ashamed! Interesting, I'll have to read the documentation on that out of curiosity. I'm just designing my signal chain in the Audio System Design Tool. (There are going to be 144 mixer objects!) There's this snippet from the 'Notes' for...

Hi Paul, This is fantastic work. I'd like to design an application-specific audio mixer (for use in flight simulators, using an ethernet port for control), this looks to be exactly what I need. I've ordered your shared PCB from OSH Park (thank you) to experiment with, hopefully it won't be too...

Typical solution for this is to maintain a short buffer on the receiver, and then slowly servo the consumption from the buffer (either reusing a sample, or dropping a sample) to keep the buffer half filled. The clock sync on the 2 Teensy will be close enough such that sample dropping/duplication...

Frank - this looks like it could be an interesting option for T3.6 - http://www.ebay.co.uk/itm/142158928979

Strooom - Do you have a pin list of required pins? e.g. Dir/step pins on specific timer pins, etc, if applicable. Obviously most other pins can just be remapped.

I would say that if we're both going to make the effort to learn something new, I'd say KiCad is the right option despite my struggle with it. (Just needs a new way of thinking) This is almost entirely driven by these facts: - The desire to have all the screw terminals along 1 face (makes this...

Honestly I don't think I'm going to give a satisfactory answer here - as I am a user of proprietary (i.e. not open source) software (Proteus PCB Design). I've tried using KiCad 3 times in the last year and usually feel very disappointed as it hasn't 'clicked' into place for me yet. I've started...

I'm happy to report that I've got this all to work! Thank you, this'll provide many hours of fun. Note: Changing I2S object to dacs object (for Teensy 3.6 DACs) works nicely.

Superb work! I look forwards to giving it a go. I was particularly amused at the youtube automatic transcribed subtitles during the LFO modulated sound demo at the beginning 'oh no oh no oh no oh no'

I'm sorry to say that protocol analyzer costs too much for me to add it to my tool collection (who doesn't love more tools?!) so can't really help there. For that dataset I used a Dell SK-8115 keyboard. (Old keyboard, not available new any more) I was also able to reproduce the same behaviour...

I've also seen the 01 01 01 01 01 01 pattern, so I've created a dataset: Keys: 1 KB Data: 00 00 1E 00 00 00 00 00 Pass with order '1' Keys: 12 KB Data: 00 00 1F 1E 00 00 00 00 Pass with order '21' Keys: 123 KB Data: 00 00 1F 20 1E 00 00 00 Pass with order '231' Keys: 1234 KB Data: 00 00...

I don't know if it'll be of any use to you, but you might find this interesting: https://github.com/macaba/Teensy-3.2-USB

Really great work so far Paul, I'm enjoying watching your GitHub progress. Obviously extremely early days yet so this feedback has little value aside from encouragement - I'm happy to report your sketch runs quite happily for me too: (Keys: 1234)

In my mind, to establish a well-regarded Teensy based motion controller project, it's important to determine if a significant improvement can be made over existing platforms, so my opinion says that's either of these things: - Higher order motion. (LinuxCNC setting the benchmark? Aforementioned...

Have you tried running this before Ethernet.begin() It's entirely possible that the current code (from the PJRC website) you've got runs too fast as it has no delays until after all the pins have been toggled.

Thank you for letting us know! I've opened a GitHub issue: https://github.com/PaulStoffregen/Ethernet/issues/9 Paul is super busy though so we'll all have to continue adding in the reset pulse manually.

I've created an issue for this. https://github.com/PaulStoffregen/Ethernet/issues/9

KurtE - thanks for posting the link. Tim - you've got exactly the same issue I had. See the link that KurtE posted for the resolution. Edit: I've created a GitHub issue for this: https://github.com/PaulStoffregen/Ethernet/issues/9

That's good to hear - you will probably find that 1000ms delay is far more than needed, a very small delay should work. Paul - I've got some older adapter boards that don't have the reset IC (as well as my own PCBs) and now they require the additional reset pulse code - it's probably going to...

Hi Dan, I had a very similar problem to you - powering up for the first time; everything ok. Power cycle (or in my case, downloading a new firmware) = problems. Just as a quick check, try running this before Ethernet.begin(...)

MTA - a quick check... try running this before Ethernet.begin(...)

I had a quick read through your wiki - I like your plan & will follow/contribute wherever I can. I think the Teensy 3.5/3.6 is the perfect platform for this, I'd be happy to design a minimalistic CNC-specific PCB (e.g. screw terminals & buffers for step/dir, a few LEDs for EN signals...