I never know if questions should be asked on here, or on the Telegram Group. So if this belongs over there, let me know.
So imagine if you took @BrianTee_Admin 's arduino machine code, @Daniel 's switch code, and the teensy ethernet communication code from the AIO, put them in a blender, and uploaded the result to a teensy. That’s sort of what I did. Everything works fine, except occasionally I get random disconnects from AOG. It’s fairly elsuive, never anything regular, so is a real pain to debug. The one thing I have figured out(I think), is that it is somehow connected to if the teensy is powered over USB. USB power connected-all works. USB not connected-will disconnect at some point. Sometimes within 1 min of getting disconnected. The next time, it will work for an hour. And I can’t really sit and watch it for an hour on the serial monitor in the field. I’ve been powering it from the 12v power outlet and that seems to be fine, not like it needs actual serial communication.
The teensy is powered through Vin with a 5v power regulator. And the teensy always holds power(led’s stay on, serial monitor works). Even when teensy disconnects from aog.
Did you cut the solder jumper on the bottom of the Teensy since it is being powered by 5v on Vin? It is not recommended to power it via Vin and USB at the same time.
No, since I lose ethernet if the teensy isn’t powered by usb. Is the power recommendation to protect the teensy, or the laptop? I have a modified USB cable with the power wire cut that I use when connected to the laptop.
Oh and if I unplug and replug the ethernet cable during normal use, reconnect works. When it malfunctions, and disconnects, nothing will reconnect until I power off the teensy. Then everything works till next time.
Here’s the Machine class I’ve been working on. It doesn’t have the section switch code in it yet and no Ethernet reconnect code but it seems to reconnect anyways with the static IP. Machine_Class 240224.zip (12.5 KB)
Please let me know if you discover bugs, I’m very actively working on it.
I’m curious if mine has the same issue on your hardware.
Sounds like a power issue perhaps. How much current is he regulator spec’d for? Are there capacitors for filtering? Any other components on the same 5v bus?
Complete re-cycle is necessary. Unplugging the usb does not help.
Will definitely take a look!
I think maybe I should write(or remove everything else), code to reply to AgIO hello message and put it on my teensy. Should guarantee that it is the SW then.
That’s what I keep thinking, but the teensy is powered by a power regulator module off amazon https://a.co/d/aLmAi6P.
3.5A max.
I don’t know. As far as I know I’m not. You might have to explain a little. I am fairly new to ethernet communication, and at all advanced microcontroller programming in general.
Also cutting the trace is a measure to protect your USB port and any 5v power supplies external to the teensy. I believe most modern USB ports have protection features which should prevent damage but it is good to be safe. Also I believe the AIO board V4.4 and up should not require the trace to be cut as external diodes were added to the pcb
To be clear the D20 diode will lover a little the 5v coming from the board so it should not harm the computer board if the trace is not cut.
But the good practice would be to still cut the trace on the Teensy so both power source will be completely isolated.
With this new pin soldered the Teensy can still be powered by the USB port (no 12v required) for firmware update.
That was the goal for this modification.
OK. Did a little testing. Used my teensy ethernet tester ( code here), it simply replies to AgIO hello message, and records how many times the watchdog timer goes above 19. And that ran for 15 hours without ever firing. I then put the debugging code in the tester in my main switchbox code, and let that run for 9 hours. It lost connection after 1.5 min and never got it back. Trying to ping the module also didn’t work, just got the destination host unreachable warning. This time, I had my computer with me, and uploading new code(with a few serial prints in it), “reset” it enough that it reconnected. So it would seem like complete teensy reset is needed before it will reconnect.
@Guy1000 could you explain a litttle? As a lot of the code is copied from elsewhere, I don’t have a full understanding of how it works.
I’ve had my simple machine class example for Teensy run for hours but I have noticed when I use it in a larger (much more complicated program) there are times that it shows a UDP comms timeout. I’ll have to add some more debug statements to verify if the autosteer PGNs also stop or just the machine PGNs.
The Ethernet on the teensy and many other microcontrollers set aside a portion of ram in DMAMEM that is used by ethernet. What I suspect is happening is if you have a program that uses enough ram in that space it will overwrite the ethernet parts and cause issues. Just look at the output of the IDE after you upload and see how much DMAMEM is left available.
I know with other microcontrollers with hardware ethernet you have to setup protected regions of memory to prevent this from happening and I am wondering if there is something missing n the teensy ethernet setup.
