Search results

(ChatGPT?) I was going to say exactly the same thing. N

I'm almost embarrassed to post this given I know there MUST be a better way to read the line of GPS response and parse it, but this does work... I wrote this because many Chinese GPS modules either don't save the default LS, or their batteries are dead and every time the unit restarts, you get...

Excellent - thanks for the confirmation Paul (and thanks for the work KurtE!) ... I'll back out my changes to the cpp files and use the functions where needed instead. Cheers - N

Historically (years ago) I had an issue which required me to increase the serial buffers on a HW serial port on a T3.5 at the time - and I found some references to changes needed in the HardwareSerial1.cpp file as shown here... #ifndef SERIAL1_TX_BUFFER_SIZE #define SERIAL1_TX_BUFFER_SIZE...

I have been using fastLED and seeing a few bits of odd behaviour (like the first couple of LEDs not lighting if I .show() too soon after setting the pixel colours etc... Odd stuff. I have managed to make it work by re-ordering some code but I feel like I am working around strangeness. I am...

Thanks all - I may end up looking at the Nextion handler and seeing if there's a more appropriate way that just hanging around and waiting for the reply... It seems pretty sub-optimal as is. Cheers - N

Well, having peppered the code with a bunch of calls that measure time spent in each function, and having noticed that the issue doesn't seem to occur on a remote unit without a display connected - I think I have found the culprit. There's an interaction with the traffic I am sending over...

On another note, I wish I hadn't aliased Serial5 to rs485 - it's caused so much confusion here. I am not using and rs485 libraries. I'm just outputting data to Serial5 on the T4.1 to a UART-RS485 adaptor which goes into an ebyte LORA DTU over 485. Cheers - N

Thanks Kurt.. I have been using a bunch of sprinkled print statements, in fact, this function has been useful for basic tracing of how long between lines being executed... I remember being quite happy to find '__LINE__' :-) whereami(__LINE__); .. void whereami(int linenumber) {...

I really appreciate the educated guessing here. I am painfully aware of how hard it is to troubleshoot something with a very small subset of the information... That's the RS485 module I am using - I am not using any specific library - it's just TTL out from the Teensy 4.1 Serial5 into the...

The commands themselves take only a few microseconds to execute, but measuring the entire main loop execution time shows that when they run within that one second interval (triggered by an intervaltimer that is disciplining the clock from the GPS PPS), the max_loop_execution_time for that second...

Fair point, and I KNOW I am leaving a lot undocumented given the size of the program, but I am not using an RS485 library, I'm just writing out to serial5. Also, I am using a Teensy 4.1 - Sorry, that was originally in the post. (But I helpfully edited that out at some point before posting!)...

I'm trying to track down a horrible situation where when I write 32 bytes out Serial5 (115200) to a TTL<->RS485 module which then sends it to a LORA DTU - my main code halts SOMEWHERE in a reasonably complex main loop. Main loop typically has a per second worst case execution time of...

Yep, well worth trying... I'll try that tonight when I take a deep breath and test all 6 GPS modules I have against it... I also aborted the shielded case for the module at this stage until I try all the modules I have. I'd love to find an issue apart from "interference" as that's the hardest...

Fascinating... In the interest of replicating the issue with slightly different hardware to eliminate a broken/flakey unit... I swapped in a different GPS module... I was using the larger Ublox M8N with integrated antenna (hmmm) and swapped in the smaller 7M instead (no integrated antenna). (I...

Interesting. This is easy as I have a few lying around... I know very little about magic airway electricitymagics - are you suggesting the interference may be feeding back (?) into the board from the LORA box? I imagined (with no basis except for it feeling right) that the interference would...

The LORA box is powered from a 9v buck converter and the Teensy is powered from a 5v buck converter. On this test rig they are both powered from a large 20v drill battery. The GPS is powered from the 3.3v VCC from the Teensy. I don't really think power is the issue as when I physically move...

Sigh. I knew I should have done 5 mins more testing... Just observing the PPS LED on the GPS unit shows that it's the GPS unit being badly affected by the LORA... The PPS stops for a few seconds when the LORA transmits. I will have to look into whether it is rebooting and why. (interference...

HI all - no code here because I don't think it's the code. Please tell me if I'm possibly wrong about that. I am using a Teensy 4.1 with a Ublox GPS on Serial1 and an external Ebyte LORA transceiver via a UART to RS485 converter that's on Serial5. Serial1 is at 115200 and Serial 5 is at 19200...

Thanks. It's not the end of the world as anything less than perfect needs to be compensated for in my application - I need ms synced separate units, but might be worth noting somewhere on the specs somewhere as it's about double the published tolerance in less accurate unit. I have no reason to...

Just noticed that you also have a 40ppm T4.1 (although a micromod)... My most recent post in this thread shows that yes, I have different crystals on two fullsize T4.1s... It seems that some of the crystals are out of spec :-( Cheers - N

In fact, checking under a microscope seems to show both the 24Mhz and 32.768kHz crystals are at least visually different on the two types of T4.1 I have that are giving in and (apparently) out of spec crystal performance. The good (10ppm) Teensy is the one on the left with the "2400T" 24Mhz...

Interesting... a 3rd T4.1 and this time I get the ticks evening out at about 999990 ticks, while the first two were both around 999960... This one was bought at a different time. I will try them all in the same board with exactly the same build and compare - but I suspect some of the T4.1s I...

I did sub in a second T4.1 (purchased at the same time as the first, from Sparkfun) and got results very closely aligned with the first example (40.2 - 40.6 ppm) It doesn't really worry me as I am moving to a new approach to keep my timer in check using a DS3231 (paying attention to the type of...

This T4.1 behaved the same when just hooked up with jumpers (eth port was on it's own little breakout)... I do have quite a few T4.1s and based on your comment I will swap a few in over the next few days and see how they behave. (Yes, the board I am using has a socket for the T4.1) Cheers - N

Thanks for the pointer, the other 2 don't appear to be broken out on the T4.1 (GPIO_AD_B0_14 and GPIO_AD_B0_10)... I'll not bash my head against that brick wall any longer and embrace pin35 with a selectable trace on my next board spin :-) Cheers - N

Ahh, thanks for that - I wasn't aware that there were limited working permutations and the pin was dictated by the hardware design. As it happens I just soldered a wire from PPS to Pin38 on the Teensy socket and cut the trace that goes to pin35... Works fine now obviously but a little messy. I...

I have managed to get this working great myself however I have some general purpose boards I have made up with eth, buck converters and sockets for GPS, buzzer, BT module etc and my PCB uses pin 38 for PPS, not pin35. I found this in the code in inputcapture.cpp // TODO: this is hardcoded to...

Coming back to this - I put a 100nf cap across the input and this has tamed the behaviour sufficiently. It looks ok on the scope now and I am not seeing any phantom triggers in the normal program execution. Cheers - N

Thanks for those suggestions. I do like the idea of a clean test using a digital output to verify behaviour. I'll have a crack at that this evening. And Mark, yes, I have seen this behaviour with switches connected as well. It's nowhere near as frequent, but it is there. I'll see if I can get...

This is the 3rd test config that displays the issue. 1) Fully populated PCB with quite a few other components 2) PCB with only the T4.1 and input connectors/pullup resistors populated 3) The bare board / breadboard as seen in the video. All give the same behaviour so this particular test setup...

Thanks Mark - I am aware that just touching the pins with an ungrounded source isn't the best idea but I get this behaviour (far less often but still often enough to break my use case) when I have a button connected to each input. This was just to demonstrate the issue in a reproducible manner...

I have 2 digital inputs configured on a T4.1. Each has a 10k external pullup. I have been finding in my full build and code that I am getting occasional instances where when only one input is closed, both routines fire. I built up a bare PCB with only the T4.1 and the inputs/pullups and had the...

It's back to weekday working so it might be a night or 2 before I can get back to this... I'm trying to come up with a small synthetic program which will capture and log the behaviour instead of me having to run through program logic at human speed... Cheers - N

Thanks for the thoughts - the switches are connected to the board through 2 pin JST connectors and about 10cm wires. I have already swapped the 2 switches around and the issue followed the Teensy pin, not the physical switch (or wiring). I have also tried a differnet PCB and Teensy 4.1. Problem...

Thanks... The PCB I made had the primary 2 inputs with the external pullups but I broke out another 6 pins for future less critical use and didn't put pullups on them. I will switch the beam inputs over to 2 of those and see if I can replicate. I have also tried not using INPUT_PULLUP on the...

Nevermind, thanks for looking at it... Also, your reply has taught me something new... I didn't know that interrupts at the same default priority would queue! If nothing else that gives me some basis for understanding why the order of the (nearly) simultaneous executions is always in the same...

Sorry yes I wasn't 100% clear on that. I was using the times on the serial monitor only to confirm that I was pressing a single button at that time... I was single finger pecking between the buttons every second or so, and at that one press at 32.313, I got a Serial output from both isrStartBeam...

I'm having odd phantom interrupts being fired on a single buttonpress. I have hardware pullups (10k) in place on 2 of the pins (22 and 23) and INPUT_PULLUP on the other (pin 2). I have only seen the behaviour on pins 22 and 23, and I THINK I have only observed pin23 interrupt firing when I press...

Thankyou for confirming that... I am fine with 150, 200, even 250ms on occasion, it's just my code wasn't taking into consideration 4 seconds of blocked execution! Since switching to TD1.54 I haven't seen the same issue occur - the times are all still around 3.5ms with maybe 1 in 50 being...

Edit - have just found reference in further searching to SD changes in TD1.53 vs 1.54 and I am using 1.53. Will upgrade now and see if the issue persists. Cheers - N

Hi all, I have an application that writes out a logfile entry every time a button is pressed (essentially) and I have noticed that I was getting odd delays and timers out of sync occasionally so I added a few basic tests for time taken for various parts of the code and seem to have found that...

Thanks gents - good thought! I'll do that this evening. I am fully prepared for the "you're doing it all wrong" because I genuinely think I am. I know _NOTHING_ about PCB layout or circuit design. I have used the PCBs as a compact way to join together modules so I don't have jumper wires going...

I am putting together a timer project that use a Teensy 4.1, GPS chip, a couple of DC-DC converters, Lora module, Bluetooth module, RS485 module, thermal printer, WS2812 LEDs, Nextion screen, keypad etc... You may have already noted that I am talking about modules - yes, these are largely...

Well I am transmitting the data across a LORA network (some ebyte DTUs including some acting as repeaters) so I want the best range/highest spreading factor and that means lowest speed - I'll probably end up at 300bps air data rate. With the equipment I am using I can specify the size of the...

Thanks for the instant response, with that extra insight it all makes sense now and I can sleep :-) Cheers - N

I have a structure I need to send across LORA so I am trying to create a CRC of the unioned char array but I am having a strange time understanding the layout of the structure. This is the structure in question struct timepacket { // 36 bytes according to sizeof() byte startorfinish; // 1...

(Maybe) final update. I set time, take a 'time_t basetime = now()' and then just add a seconds++ into the pulse() above. Any time the program wants a time, it asks for 'local = myTZ.toLocal(basetime + seconds, &tcr);'. So far it seems to work great. I wouldn't call it elegant by any stretch but...

Ok - I think I get that now... I have written what I hope is a simple program to illustrate what I am clearly not understanding. I had hoped while clearing out the other rubbish I would find what I was missing but nope! The following program exhibits almost the precise predicted drift...

I'm having a nightmare trying to get an accurate clock working on my T3.5... The most frustrating bit is that there is apparently an ideal function that will do exactly what I need but I can't make it work... Teensy3.compensate(x) Whatever I do, I can't get this to work. I have modified one of...