Hi @Doug-Miller
I can answer some questions for you:

YES, J9 USB-C now supports Host mode on this platform. Sadly, no, net yet. That was a recent discovery and we have not had a chance to determine a clean work-around aside from incorporating the series caps on your target device. We do plan to make a spin of Voxl2 mini later in the year to fix this long-term. It's not an easy effort, so we cannot just jump into it quickly. Not sure what you mean by "noting past forum comments" but if you design a simple Hub board, there are no tricks to interfacing it other than including the series caps on both TX and RX lines of the SS signals, and make sure to swap RX/TX to the hub since the notation "RX" is relative to our host. Here is a simple Schematic snippet to show you how we do it on our 5G modem (M0090) boards:
f294c43b-06cf-46e1-a25e-7bd10382fbc3-image.png We've had success using small I2C/SPI based displays on our FlightCore products, but this is starting to venture into more of a SW topic for support using Voxl2. I do not have any good suggestions, but maybe someone else from the team might chime in. The QRB5165 SPI ports are capable of 50MHz maximum. I'm not sure if SW has them setup for that. Requires someone from SW to respond. I'll ping them internally to ask someone to respond. We've just undergone a forum server update, and some of our notifications are currently down, so not everyone sees all the posts at the moment.
Thanks for your patience.

@wilkinsaf Thanks for the response, I will see if the superiors are interested. Just hoping for a bit more direction to evaluate ourselves first

@Moderator I'll take a look at that code. Can you tell me which UARTs currently are available as tty devices?

I may be able to rewiring things to use different ports while I wait.

Thanks.

@Moderator Can you take a look at my new post.
I can see that the mount command in syslog. No errors, but the mounted file system doesn't show up.

Thanks,
Brendon.

@Brendon Does your device show up with sudo fdisk -l?

On my setup, I tested with a random SanDisk drive:

The last device in the list is

Device Boot Start End Sectors Size Id Type /dev/sdg1 2048 60088319 60086272 28.7G 83 Linux

I can then create a dir to mount to, i.e.:

sudo mkdir /media/USB-Drive

and mount the drive:

sudo mount /dev/sdg1 /media/USB-Drive/

and then see the file on my drive:

voxl2:~$ ls /media/USB-Drive/ hello

@david-moro It would be better to start a new thread with that topic.

@david-moro Yes, the VOXL 2 Mini supports OV9782

@Aaron-Porter So I made a mistake that the IMU-server was not running during my screen shots. But I figured out the issue. Yo can use the starling file you have to run the command,

voxl-configure-qvio factory_enable_imu_apps

This will tell qvio-server to look for imu_apps instead of imu0.

Hi @RykerBarthold
That USB-C follows the pinout you can get from the device spec.
We list the MPN of the connector here:
https://docs.modalai.com/voxl2-mini-connectors/#summary
I must caution that you need to plan on failure here. That connector will take a lot of heat to remove and you risk damaging a lot of the surrounding components.
We will obviously not be able to offer any RMA or credit for boards that have been through this potential process.

@ATMA said in Technical specifications VOXL 2 mini:

Following on my request. Are you planning to integrate support of the lte device? Timeline?

Hello Team Modalai,

any feedback on this topic?

As the Starling also integrates the Voxl2 it seems at bit like the Voxl 2 mini is more of a future product that needs much more work to be ready. So regarding weight and size savings it could be a great product...

Thank you!

Cheers
Josua

@Vinny
Thank you so much.

Kim,

@Aaron-Porter The tracking sensor does not need to be straight, but the extrinsics need to reflect the accurate position of the sensor relative to the IMU

if you monitor the qvio-overlay in voxl-portal, it's usually obvious what is going on. If you need help interpreting, please post a screen video capture of the qvio-overlay here

@Trinadh Can you edit the file /etc/modalai/voxl-px4.conf and set GPS=NONE, RC=EXTERNAL, POWER_MANAGER=NONE, DISTANCE_SENSOR=NONE, and OSD=DISABLE. After updating that file and rebooting does the CPU utilization change at all?

Thanks @Moderator, How to connect Microhard UART to VOXL2 mini, which connectors should I use?

I am having these same issues. I'm on voxl suite 1.1.0. Voxl camera server shows 0 cameras connected. When I use dmesg right after I get this: 56fd6d22-d63c-4478-a07c-bcc3379c6b2c-image.png

My setup is as shown here:
https://docs.modalai.com/images/voxl2-mini/MDK-M0104-1-C4-b.jpg

And I've used

camera-server-config-helper hires:imx214:0 tracking0:ov7251:1

For configuration.

Am I doing something obviously wrong?

Thanks

@mkriesel Yep, exactly

@tom Yes sir.

Voxl 2 mini J9 USB port <=> Android Phone attempting to use accessory mode to directly communicate without additional external hardware for networking or similar.

I've used that port as the host for USB storage previously, ADB, etc. but this use is resisting our efforts.

OK, here is the clarification regarding camera IDs and sensormodule file names and the general process for camera detection on VOXL2 platforms

all the camera-related drivers are located in /usr/lib/camera the index at the end of sensormodule.bin filename, such as 0 in com.qti.sensormodule.imx678_0.bin is only used to distinguish the files - the actual index at the end is not being used for anything each sensormodule.bin file contains a camera_id parameter, which is read by the camera framework after loading the .bin file the camera_id is then used by the Kernel to look up the specific port information to be used for communication with the specific camera, including (but not limited to): i2c (cci) bus id, mipi interface id, reset pin and others. This information is mapped to each camera port in the Linux Device Tree. with the above information (all basically mapped to a single camera ID), the camera framework knows how to turn on the camera, which bus to use for i2c communication and which mipi port to receive the image data from after obtaining the port information, the camera framework uses other information in sensormodule.bin to detect the camera (query the WHOAMI register for camera identification). If the camera is detected, it is considered to be available for the camera framework to use (not much else is happening until you actually open the camera using the voxl-camera-server, for example). The camera framework also loads the list of available streaming modes which is also contained in the sensormodule.bin after the camera is queried / identified, it is then powered off when voxl-camera-server is started, it sees all the cameras that the camera framework already detected and their corresponding resolutions / modes. Based on the voxl-camera-server.conf, the appropriate cameras are turned on again and set to stream at the desired resolution / fps. lastly, for each camera type, there is a single .so dynamic library (for example com.qti.sensor.imx678.so) which contains functions for converting desired exposure and gain values into the register values that need to be sent to the camera.

With all of this in mind, renaming a sensormodule.bin should achieve nothing because the actual id / number at the end of the file is not used for the camera ID parameter, it is only used for differentiating the files.

If there is still an outstanding request to connect IMX678 camera to a port that is currently not supported, please let us know, we can generate and test the new sensormodule.bin files and release them (assuming there are no other unexpected issues)

Alex