Following post #33 link, DJ states not to put the baud rate in as it would default to 3,333,333 bps . Did you happen to try that? Just a guess on my part.

Thanks guys! I’ll try removing the wire on the adapter side to limit noise. This will also give me access to the RTS pin on the adapter side. I forgot to mention that I also tried switching the baudrate in the device manager to match the lower baudrate when I entered it manually in the camera skill.

@Herball yeah I was mostly testing at the default speed (ex:COM4) without the additional baudrate added.

Hey guys still working on Guardians 3 so I am away from my computer/robots/parts etc. And I have brain rot, so I've gone back over the old thread to see if anything has jogged my memory.

-I went with the revision "D", the PL2303HDX, because I knew it would be running on Win 10 (for drivers).  -Voltage supplied was 3.3v -Post #36 was the final wiring diagram that I got it to work. -Once I had a video feed I got "ripped frames" where the feed seemed to lose sync between frames.(post #37) -That was resolved by moving to a new computer and therefore a newer USB socket. All my issues went away after that. Not sure why that was. (post #48)

I have these in all my robot heads and they work great. Hope this helps?!

Thanks Will! I appreciate you taking the time to chime in!

Can I ask you if you are using the latest version of ARC with the PL2303HXD, just to rule out if there's something in the software that's different?

Well I'm starting to suspect it's my Laptop at this point. I have tried force switching different COM ports, verifying that I truly have 3.3V powering the camera (I do), tried another USB port, did continuity checks on all the connected GNDs (all good), tried 2 different FDTI FT232RL adapters (at lower baudrate COM8:115200), and tried messing around with connecting RTS/CTS to GND on the adapter side, I can't seem to get it to work. Is there a setting I'm missing somewhere maybe? Do I need flow control on?

Jer - I checked, and there hasn't been a change to the uart video code in years. The code also works because it's the same code that the TCP video uses pretty much. The message you're getting about the buffer filling is that the header cannot be identified because the data must be garbled.

Changing the baud rate by specifying it (i.e., COM8:11500) will never work. This is because the camera transmits at 3,333,333 baud, not 115,200.

Quote:

Changing the baud rate by specifying it (i.e., COM8:11500) will never work. This is because the camera transmits at 3,333,333 baud, not 115,200.

That was a custom firmware

uart serial requires both parties involved in the communication to have the same baud. The baudrate is how fast the two devices transmit and receive. If one is not at the same baud as the other, there’s no way either can understand each other.

this is because one is speaking a different speed than the other. They need to speak the same speed or it’ll never work.

what’s happening with your setup is there’s data, but it’s skipping bytes or being garbled. That could be due to a slower USB port or the uart usb converter.

the ARC parser is looking for a header which is EZIMG. It needs to find those 5 characters. Then the next 2 bytes is the packet size as an unsigned int.

if the data is missing bytes or garbled, it’ll never find the text EZIMG and therefore just continue receiving what ever data is on the wire.

If you want to test it at a different baud rate, then use an esp32 cam with the firmware I made a few months ago. There’s a version of the esp32 cam that replaces the ezrobot camera and can connect directly to an ezb. But rather than connecting it to an ezb, just connect it to your uart adapter.

In that firmware, you can change the baudrate to what ever you want including 115200

Understood, I thought the camera might have a variable baud rate, my mistake. I forgot to mention that I also shortened the wires on the PL2303TA but it didn't seem to have any effect. I also did verify that it was actually communicating properly using an Arduino Pro mini. I was able to program it. At this point, I'm going to see if I can get my hands on a PL2303HXD or equivalent or try with another computer.

*Edit: Yeah thinking more about it, I feel that it's likely the advertised baud rate of the PL2303TA is likely not up 6Mbaud, or maybe it is under very strict circumstances. The PL2303GC and PL2303HXD are rated to go to 12Mbaud so that's much higher than 3.3Mbaud, I have much more faith that those will work.