Topics created by Jeremy Frederick

Hi @Jeremy-Frederick
If you mean "2A" (not 5A) then sadly no.
Our newest 4G modem board M0130 can provide the needed 2A (10W) for full range, but otherwise, an external supply is needed for Doodle to achieve their max stated specs.
https://docs.modalai.com/cable-datasheets/#mcbl-00085
https://www.modalai.com/collections/modems/products/m0130-3?variant=48186331693360

@Moderator yep, back and forth. unfortunately no change.

I was able to replicate your issue and also confirmed that the issue goes away if I move the AR0144 camera from the M0084 cable (connected to J7L) to J6L using M0076 interposer.

I believe the issue is related to potentially insufficient decoupling capacitance in the IMX214 camera, so running it on the same flex with another camera causes noisy pixels.

I hope you can work around the issue by moving the AR0144 camera to another port.

Sorry about that!

Alex

Hi @Jeremy-Frederick
Can you please provide some pictures?
It almost sounds as if you have a faulty RJ45 jack, but these are tested in factory before shipping.
If you can get some close ups of the non-working RJ45 and the LAN7500 chip, that may help.

And, can you clarify that you have Qty-2 M0062's and one works, yet one doesn't? Did the faulty one ever work for you? Was the faulty one in any type of handling mishap (like an accidental drop/fall)?
The RJ45 has integrated magnetics to save space (which is why it is so tall), but that makes them more vulnerable to shock failure than typical RJ45's.

One thing I do know that may also occur is the jack can be installed slightly tilted, making it hard to seat the RJ45 cable in firmly. There is an odd feature on the connector that sometimes allows it to seat at an off-angle, slightly pointing down making the cable slightly interfere with the PCB (but still ok to insert, since as I mentioned, we tested at the factory). Also, the metal along the sides of the RJ5 may also be stiff, preventing a smooth insertion, so sometimes just inserting the RJ45 cable a few times making sure you get that nice tactile "click" may be what is needed to ensure the contacts are engaged and kinda "breaking in" the stiff connector.

Hi @Jeremy-Frederick
This appears to be a fusing open of some (one or more) power signals on the flex, indicating that excessive current was demanded of the flex. A short at the image sensor module of a power rail could cause this, so a loose connector may have certainly been your culprit, and a voltage likely contacted a GND signal or component.

@Jeremy-Frederick, that is great!

Luckily (or by design 🙂 ) the camera connector reversal is typically not fatal, but DO NOT push your luck, please 🙂 . Technically, if damage occurs due to incorrect insertion of the camera connectors, this will void the warranty for the main board.

Always verify connector orientation when changing camera configuration.

Alex

@Jeremy-Frederick , If VIO is working, then there is a very high chance that you got the orientation correct 🙂 . If the camera to IMU orientation is off by something like 90 degrees in any direction, VIO is pretty much guaranteed to fail. So if you are getting normal VIO performance, quick initialization, across multiple tests, then I would say that your orientation parameters are correct for VIO.

Please keep in mind that if you flipped the board and if you are planning to fly with PX4, you will need to change the imu rotation params in PX4 (also keep in mind that PX4 is using a different IMU that is connected to the DSP)

@Moderator Great, I noticed in SDK 1.2 there is now support for dual tracking cameras in the camera server, can both feeds be fed into the QVIO service to allow for the use of both cameras in VIO?

@Alex-Kushleyev I appreciate it, all is working now

since voxl-streamer can provide RTSP streaming from VOXL2, ffmpeg can be used on the host machine for recording outside of QGC.

You can find some helpful information by searching ffpmeg save rtsp stream to a file . for example : https://medium.com/@tom.humph/saving-rtsp-camera-streams-with-ffmpeg-baab7e80d767

@Jeremy-Frederick No, it should not ever crash in mid flight! Can you provide the console output (journalctl -b -u voxl-px4), px4 log, and dmesg output from one of these in flight crashes so we can try to figure out what is going on?

@Jeremy-Frederick Can you try to lower the bitrate or resolution to see if it's a bandwidth issue?

I understand that, in theory, the rendering software (VLC or QGC) shouldn't matter for your issue. But, it typically helps to see if there is a config that will work reliably and then push it from there.

@Eric-Katzfey This is working great, been playing around with it for the last week or so. The next thing I'll be working on will be the order in which the cameras streams are displayed to QGC. It seems right now on boot the initial stream that comes up in randomized over the various camera being fed into QGC.

@Jeremy-Frederick

I would look at this being a radio thing. I would try

get some distance between the radios. if they are too close together there might be too much noise in the system monitor the radio health when you see the cut out (should be able to see that from the menu of microhard 192.168.168.2) see if this happens if you connect over straight ethernet (use this cable: https://www.amazon.com/USB-Ethernet-Adapter-Gigabit-Switch/dp/B09GRL3VCN/ref=sr_1_2_sspa?crid=1ZBIC6DOI8DB5&keywords=ethernet+to+usb+adapter&qid=1699997723&sprefix=ehternet+to+usb%2Caps%2C124&sr=8-2-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1). If you dont see the issue, i would look closer into how the radios are configured antennas: make sure you have the right radio antennas suggested by microhard

@Jeremy-Frederick

Or, you can add this feature in PX4. but, this would take more time to implement

@tom SOLVED, thanks Tom, that command line prompt showed me that I needed to voxl-configure-extrinsics. Thank you!