CM4Ext Nano OpenHD Edition?

[harlab]

Hi, it's nice to see interest from OpenHD community.
We are looking into designing other versions of CM4Ext Nano board and we might come up with solution that you need.

Please list all specs that you need, like:

• camera? Pi v2 or HD?
• do you need stereo camera?
• power input? 2s-6s was mentioned
• GPIO, sensors, telemetry connectors?
• buttons, LEDs?
• what WiFi dongles and chipsets are you using or would like to try?
• anything we need to know

Board production and testing requires quite amount of time and money, but since this is experimental community driven project, we need your assistance:

• mark this post with Rocket if you are in Bayern (or close) and willing to do flight tests of prototypes.
• mark this post with Hooray if you consider buying this board when it will be available.

[Consti10]

Hello, I am from bavaria, Munich ( So I can buy and test the board as quickly as possible). I am also a Developer on the OpenHD system.

1. A typical setup uses 1 high powered wifi card on the air, connected via USB. It would be nice if the board could provide this (much) power via the USB connector
2. Depending on the user the camera might be a usb camera (see https://github.com/OpenHD/FPVCamera/blob/main/README.md ) or a CSI camera ( currently still the most used option ).
   So it would be nice to have up to 2 usb ports working simultaneously.
   (Optional,I think you need another chip for that with the cm4, right ?)
3. Smaller usb connector(s) than "full usb connectors" are preferred.

[knputyi]

or maybe usb "trough hole" breakout for wifi card connection...

[CopterGUI]

Hey Harlab
Thank you for the fast reply and your suggestion of a custom OHD board.

In my opinion your design is close to ideal for our use case as is, besides the mentioned things which can be overcome easily with an external dc/dc + usb hub.
Im just a user but I will try to answer your questions:

camera? Pi v2 or HD?
--All of them + usb cams, so a second USB port would be nice.

do you need stereo camera?
--Yes. For stereo or just switchable multiple camera Input. I think for us it is more useful than the display port. At least when used air-side. I was very happy that you have a 4 lane camera connector already.

power input? 2s-6s was mentioned
GPIO, sensors, telemetry connectors?
-- We use the Pi's telemetry port on pin 8+10 and some cameras also use the i2c.
Yes 2-6s battery input. No sensors.

buttons, LEDs?
--2 dip switches on GPIO 20+21 for profile selection maybe. Not necessarily

what WiFi dongles and chipsets are you using or would like to try?
-- usb-ac56 from asus is the most popular at the moment. Anything with a rtl8812au or atheros ar9271 and some other chipsets are supported. If you think about an integrated wifi solution - that would be the holy grail at the moment. In this case the rtl8812au and a hefty amplifier is very much preferred.

anything we need to know
-- we need everything as small and light as possible :)
I personally prefer solder pads over connectors for usb and power. Maybe both is possible.

I also live close to Bayern (Heidelberg) and like to offer test flights if needed.

Best greetings,
Sebastian

[harlab]

Hi @Consti10, good to hear that developers nearby available. That would make testing easier when hardware involved.

1. For those who can't wait, current CM4Ext Nano board can be modified by user to disable current limit. To do this, just short polyfuse pins (big SMD part between USB connector and ACT LED). I tell this, assuming that most FPV guys can solder and do have soldering iron. For dedicated OpenHD board that will be removed.
2. I walked through OpenHD repository and see that you mostly use RTL chips with drivers that enable monitor mode/packet injection. These RTL chips do have version ending with -e instead of -u - those are PCIe versions of the chips. Do you see advantage using miniPCIe/m.2 WiFi cards over USB? To my opinion, in this case you'd have WiFi right on the board and SMA (or two) connectors to place antennas anywhere you want on a drone. In addition to this you'd still have one USB for camera without using USB switch. Technically, I don't see any problems putting switch, those are cheap and easy to use, but having dedicated interfaces for each periphery sounds better to me in terms of minimizing latency.
3. I get your point regarding connector type. Smaller is better and something on vibration resistant side, rather that hot-gluing)

[steveatinfincia]

2. I walked through OpenHD repository and see that you mostly use RTL chips with drivers that enable monitor mode/packet injection. These RTL chips do have version ending with -e instead of -u - those are PCIe versions of the chips. Do you see advantage using miniPCIe/m.2 WiFi cards over USB?

Yes, that would be preferable for a variety of reasons. Without using a USB3 controller connected via PCIe (like Pi4b), the USB wifi cards end up being connected to the older OTG port on the Pi, which has always had timing issues that have had significant impact on transmission and reception.

Some of the other boards we're going to support have actual PCIe card slots as well.

One thing I don't know yet is how the PCIe signaling would affect the transmission. On the Pi4b it should already be a factor but no one has checked with test equipment or compared. We know that USB3 signaling can affect it, though most people solder just the USB2 wires which avoids the problem.

3. I get your point regarding connector type. Smaller is better and something on vibration resistant side, rather that hot-gluing)

Definitely, I've seen some other boards using the same style connectors that Pixhawk uses, like the DCDZ Jetson Nano carrier board. They're quite nice, and it's great to have something semi-standard to use.

[harlab]

Hi @CopterGUI, nice to see that local test team can easily get together and your input on technical details is exactly what we need.

In my opinion your design is close to ideal for our use case as is, besides the mentioned things which can be overcome easily with an external dc/dc + usb hub.

We feel that it's much nicer to have a clean assembly of a drone with minimum zip-tied/velcroed/hotglued parts, especially for 250 class, not to mention reliability. So current plan is that test-pilots to have prototypes, for OpenHD PCB production we need I'd say at least 50 orders.

camera? Pi v2 or HD?

All of them + usb cams, so a second USB port would be nice.

Question was related to one possible implementation option, where you throw away PCB from V2 camera, connecting it directly to CM4 carrier board, making it very compact. Let me know if this is a nice option, or you prefer to have external camera anyway for CoG/layout issues.

do you need stereo camera?

Yes. For stereo or just switchable multiple camera Input. I think for us it is more useful than the display port. At least when used air-side. I was very happy that you have a 4 lane camera connector already.

Having both CSI available is not a problem, but note that CM4 exposes 2-lanes for CSI0 and 4-lanes for CSI1.

We use the Pi's telemetry port on pin 8+10 and some cameras also use the i2c.

Is telemetry 3.3V UART?

usb-ac56 from asus is the most popular at the moment. Anything with a rtl8812au or atheros ar9271 and some other chipsets are supported. If you think about an integrated wifi solution - that would be the holy grail at the moment. In this case the rtl8812au and a hefty amplifier is very much preferred.

Regarding WiFi please take a look at reply to @Consti10 and what do you think about still having one USB, but miniPCIe for WiFi?
"hefty amplifier" - are you using external PA+LNA? If yes, this what voltage do you need to power it and are there any links we can look at?

I personally prefer solder pads over connectors for usb and power. Maybe both is possible.

Note taken)

I also live close to Bayern (Heidelberg) and like to offer test flights if needed.

This is great) But ground tests first. If you guys give a go for mini PCIe, then we will need to test WiFi adapters first on CMIO board.

[CopterGUI]

We feel that it's much nicer to have a clean assembly of a drone with minimum zip-tied/velcroed/hotglued parts...

--Yes you are right, it's much nicer

Question was related to one possible implementation option, where you throw away PCB from V2 camera, connecting it directly to CM4 carrier board, making it very compact. Let me know if this is a nice option, or you prefer to have external camera anyway for CoG/layout issues.

I think external cameras are preferred because your approach would limit us to a single possible sensor, and the v2 sensor is not that good.

Also I like to mention that At the moment we are using external csi-hdmi adapters to connect hdmi cameras. They are based on the Toshiba TC358743 chip. To implement that chip to have direct hdmi input is another idea.

Is telemetry 3.3V UART?

That depends on the specific flight controller, but 99% of them have 3,3v UART yes.

Regarding WiFi please take a look at reply to @Consti10 and what do you think about still having one USB, but miniPCIe for WiFi?

What Stephen said above ^
(He is the main dev of OHD btw)

"hefty amplifier" - are you using external PA+LNA? If yes, this what voltage do you need to power it and are there any links we can look at?

I was referring to something like the skyworks SE5004L. A high power smd amp for the 5,8 ghz band. It's powered by 5V

[steveatinfincia]

Question was related to one possible implementation option, where you throw away PCB from V2 camera, connecting it directly to CM4 carrier board, making it very compact. Let me know if this is a nice option, or you prefer to have external camera anyway for CoG/layout issues.

I think external cameras are preferred because your approach would limit us to a single possible sensor, and the v2 sensor is not that good.

And keep in mind that it isn't going to be much longer before any of a large number of CSI sensors can be used on the pi, rather than just the few they released themselves (the older firmware camera stack is being replaced with an open stack based on libcamera).

[Consti10]

I think this quote is actually one of the most important ones:

Yes, that would be preferable for a variety of reasons. Without using a USB3 controller connected via PCIe (like Pi4b), the USB wifi cards end up being connected to the older OTG port on the Pi, which has always had timing issues that have had significant impact on transmission and reception.

But the only reason to use a PCIe card instead of a USB wifi card would be the fact that the CM4 routes out the PCIe connector and no proper USB 3 ports.
So the only reason that would justify PCIe connectivity in contrast to USB 3.0 would be if adding a USB controller to the motherboard is so expensive / difficult from a PCB manufacturing view that it overweights the following advantages of 1/2 "good" usb ports:

1. Users can re-use their existing wifi adapters (really important)
2. USB wifi adapters are well tested and available everyhwere, PCIe cards are not
3. USB can work over distance
4. if the on-chip USB port of the rpi is really "that bad", usb FPV cameras are going to have issues when connected to it, too

[harlab]

@steveatinfincia, @Consti10, we need to agree on interface configuration, below are options, including hardware to test (omitting CSI options here for clarity and feel free to add if something is missing):

1. USB WiFi + USB camera on native SoC USB2.0 port. Cheapest, but lowest performance. Can be tested with RPi4B + USB switch on USB OTG port.
2. USB WiFi + USB camera on USB3.0 controller via PCIe. Can be tested on regular RPi4B.
3. PCIe WiFi + USB camera on native SoC USB2.0 port. Can be tested on CMIO board with PCIe to mPCIe adapter and WiFi card.
4. PCIe WiFi + USB camera on USB3.0. Requires PCIe switch, USB3.0 card, PCIe to mPCIe adapter and WiFi card.

Options 3 and 4 give possibility to build more integrated and cleaner setup, but requires more testing and evaluation of mPCIe card. I can support these tests providing CMIO, CM4, USB3.0 card and PCIe switch, while you'll need to have PCIe to mPCI adapter and variety of mPCIe cards. Can also support range test in field.
PS: mPCIe can be m.2 WiFi card instead

What do you think?

[Consti10]

@harlab
How hard is it to place the Via Labs VL805 chip (e.g. the USB 3.0/2.0) chip connected via pcie on the rpi 4 on the CM4Ext-Nano board ?

[harlab]

@Consti10

How hard is it to place the Via Labs VL805 chip (e.g. the USB 3.0/2.0) chip connected via pcie on the rpi 4 on the CM4Ext-Nano board ?

I really meant this one for options 2 and 4

[Consti10]

As soon as I can get my hands on the CM4Ext_Nano I can test how well the original USB connector works for OpenHD / wifi cards. Maybe it will work just fine. Any info when / where it will be available ?

[CopterGUI]

I want to give my 2 cents and vote for option 2.

Because:

1. no tested pci WiFi cards available. And people will want to use their old cards.

2. with only 1 available USB port this board can basically not be used as a ground unit. What a shame as it could fit inside a standard RC transmitter module bay.
   (1 Vertical hdmi Port possible maybe ?)
   Please correct me if I'm wrong but:
   We basically tested all this over many years with all the pi models and the problems we had with usb never happened With the Pi4 So Option 1 and 3 are not an option.

3. option4 sound like a lot of work and money

[machadofelipe]

my 2 cents:

• CSI mapped with 4 lanes;
• Consider one design more focus to Ground unit (no need for cameras but might be interesting an IC for watching battery voltage and current consumption) and one for air unit (no need for HDMI?).

But all the other guys already gave very good suggestions :)

[harlab]

@Consti10, @CopterGUI ok, maybe we’re making a ~4 weeks pause here, then we can provide CM4Ext Nano for testing and maybe one or two prototypes of future boards. But if you’d like to make a test with CM4 and CMIO, we still can provide those for a couple of days.

@machadofelipe any links to ground units build to see how it looks like?
Can this be interesting for you?
https://github.com/harlab/CM4_LCD_LT070ME05000

[Consti10]

That makes sense. However, if you could share prototype designs with us (aka 3D rendered picture) that would be appreciated. I am curious to how these different designs 1-4 could look like.

[CopterGUI]

Here is a link to some grounstation builds:

https://discuss.openhdfpv.com/c/custom-tx-aio

[harlab]

@Consti10 No matter what option to choose, it's likely to stay in the same 55x40 footprint, because with GPIO, audio, HDMI and Grove connectors removed, there is enough space to implement any features. USB2.0 connectors to be replaced with JST 1mm pitch with soldering points near connector for those who like to have everything solid. As for now, we need some more time to prepare hardware for your tests.

@CopterGUI Thanks for pictures, really nice. If I get it right, air unit has higher priority for community over ground stations and those are two different projects. Just had an idea if Raspberry pi 3D glasses would be any useful

[the-nicolas]

I also want to join this discussion. That sounds all very promising! It should be easy to collect enough orders for that board, I need at least 5.

@harlab I am also from Munich and would be happy to help with testing. I do daily test flights even in winter. If you have anything working (even actual nano) let's start. I can connect some usb hub in the meanwhile to connect my 2 usb devices and also power them with that.

[harlab]

Hi @the-nicolas, good to hear more people available locally for testing.
Can you develop test program, ie what we actually test: latency, stability, latency vs resolution, stability vs resolution, etc? Also, I'd appreciate if you can prepare air unit SD card. With this we can start testing some configurations even this weekend. For test repeatability this should be ground test at the same location and distance between units

[harlab]

By the way, I got 5" 720x1280 IPS LCD running on CM4: https://github.com/harlab/CM4_LCD_LT070ME05000/blob/main/Documentation/JD9365Z.jpeg
Wonder if there is any use for GS or as VR with 10Eur glasses https://www.conrad.de/de/p/renkforce-rf-vr1-schwarz-virtual-reality-brille-1462833.html

[Consti10]

For VR with OpenHD I wrote this app:
https://github.com/Consti10/FPV_VR_OS
If you already own a high-res smartphone this is probably the way to go, unless you want to do everything DIY.

[the-nicolas]

Can you develop test program, ie what we actually test: latency, stability, latency vs resolution, stability vs resolution, etc?

@harlab What does that has to do with the carrier board? These tests are rpi relevant and go hand in hand with used wifi card and distance...

For the carrier we just need real life stability tests under different em/power environments. In my experience no theoretical test make sense, you need to put that stuff in the air. Having the other rf stuff, motors, esc, FC etc. around brings up the real problems. On the bench normally everything works...

[Consti10]

I kinda agree with nicolas. OpenHD doesn't have any "extraordinary" needs regarding stability except the usb-wifi-card issue.
And to test that you need OpenHD on the ground and air.
Btw, one recent development I'd like to share here:
While I know that the 720p60/1080p30 encoding limitation on the rpi sucks, we are probably stuck with that for some more time to come.
However,there seem to be quite a lot of "new" (or semi-new, I just heard abut them recently) CSI modules with an integrated ISP.
720p60 is not too bad for FPV if the image comes from a well-tuned ISP + camera module.
And if clocked correctly, the rpi can do 720p60 encoding in less than 20ms.

[harlab]

@the-nicolas, @Consti10, what I mean by "tests" is not to test OpenHD or particular WiFi card, but to choose one of baseboard hardware configurations from listed above.
If most you vote for option 2 with USB WiFi + USB camera on USB3.0 controller via PCIe, just like on RPi4B, then we can skip hardware evaluation and summarize specs:

• VL805 for USB
• 2x CSI 22-pin connectors
• 2-6S to 5V PSU
• UART and i2c connectors for telemetry
• Solder pads in parallel to connectors
• optional 2 DIP switches for profile selection
• optional TC358743

Now questions:

• how many USB ports do you need out of 4 available?
• do you need any of those to be 3.0? How many (max - 2 USB3.0 ports)?
• do you need regular connectors for USB or "custom" connectors + solder pads is fine for all ports?
• add specs if I've missed something going through the page

[howels]

Sorry for the confusing mention. Watching this thread with interest 😁

[the-nicolas]

Alright ;)

Definitely option 2:

• I would make all USB ports available - at least via solder pads
• In general I would follow the pixhawk way and use JST-GH connectors for UART/I2C and also for at least 2xUSB (but the sockets are light I would recommend even 3 or all 4)
• There is no need for USB 3 in my opinion
• 5V PSU should be able to deal with low input voltages (5.5V), because 2S Lion can go lower than 6V
• TC358743 would be really cool and I guess Mini HDMI is the only connector which makes sense (micro always breaks)

Idea: It would be good to have the possibility to switch the power of the USB devices. Sometimes devices crash and it would be good to shut down the power during a reboot of the CM, that everything can fully recover...

[Consti10]

1. I2c and UART should definitely use already soldered connectors. JST-GH seems like a good chice.
2. what determines if the port is 2.0 or 3.0 ? Note that if we already use a chip with 2 x 3.0 ports it makes less sense to not expose 3.0 ports. Especially since some USB cameras need 3.0 speeds for raw data.
   Has anyone tested how different (small) connectors other than the standart usb / micro usb influence usb bitrate and signal integrity ?

One more thing: If you need input which connectors to use, here is a shop that sells a carrier for a chinese version of rpi 3B+
https://item.taobao.com/item.htm?spm=a1z10.1-c.w4004-5688490577.11.d0983675MYghky&id=634920431073
Note: even though advertiesed as "for OpenHD", we have never spoken to this guy.

[harlab]

@the-nicolas thanks, should be possible to switch USB power individually

@Consti10 USB2.0 has one differential pair with bitrate 480Mb/s and looks like it can somehow tolerate moderate spaghetti wiring. USB3.0 has two more differential pairs with bitrate 5Gb/s. To miniaturize USB3.0, USB Type-C connectors can be used.

One more thing: what's max total current on all USB connected devices?

[CopterGUI]

Good Morning everybody,
Nice to see the progress :)

Some more notes from my side:

• the profile selection DIP switches are only useful on ground side, so for a air-only unit these can be removed.

• ideal USB setup imho would be:
  2x custom usb2 connectors + pads behind
  1x usb3/c
  1x usb2 solder pads only

• I don't think power switches for usb are useful.
  @the-nicolas are you thinking about that runcam webcam ? I never had a single problem with usb devices crashing.

Total current is arround 1A average for a high power air setup. With quite high spikes. This includes the Pi already.
I general PSU's rated 3A or more are working fine. Raising the voltage to arround 5,10V - 5,2V seems to stabilize the system.

[steveatinfincia]

Especially since some USB cameras need 3.0 speeds for raw data.

If Intel's testing data is correct, having those extra USB lanes running with a 5GHz signal will interfere with the wifi cards, but we should test it ourselves, because they would be useful.

If it's a problem at all, it may only affect receiving RC signals on the air side, and traditional spread spectrum RC signals might not be vulnerable.

[steveatinfincia]

the profile selection DIP switches are only useful on ground side, so for a air-only unit these can be removed.

They won't be needed anyway, most people were using them to switch settings for different vehicles, and vehicle settings follow the vehicle now. The other reasons people were using profiles no longer require settings at all.

[CopterGUI]

the profile selection DIP switches are only useful on ground side, so for a air-only unit these can be removed.

They won't be needed anyway, most people were using them to switch settings for different vehicles, and vehicle settings follow the vehicle now. The other reasons people were using profiles no longer require settings at all.

Ahh good to know. Thanks

[the-nicolas]

• I agree that DIP switches make no sense. I use them right now on Ground, but even here I have soldered cables to have the switch accessible without opening the case. If there is any reason in the future to have a switch, it should be okay to solder it to some gpio.
• The maximum USB current rated at 3A should be fine
• I also agree with the USB configuration and raised 5V voltages of @CopterGUI
• Regarding USB3: It should be no problem to have one usb-c socket onboard. It should be placed as close to the chip as possible and the risk of interferences just rises, if that port is used. Just having it is no risk, but an option. But soldering and USB3 fits not together, that just works for USB2.
• I still would prefer a solution to have all (not individual) USB devices de-powered during reboot. A reboot should be 100% the same as a hard reset. I had problems with 4G sticks in the past and also with other devices after lost packets. Perhaps because of not 100% reliable connection, some interference, power spike, WHATEVER... so having the possibility to fully restart the system is always a win. Perhaps even an external watchdog ic for 20 cent which disables the main voltage regulator for everything (even the CM) for 2s is worth thinking about.

@steveatinfincia You remember the problem that Rpi4 got stuck during reboot and needs full reset? Having a reliable way to remote reset a system is really worth investing a few cent, loosing a model is way more expensive.

[CopterGUI]

I can confirm OpenHD 2.0.8 Buster works just fine on CM4 + IO board. Boot from eMMC. Air and Groundside. I used a single usb-ac56 on both sides and arducam imx477mini csi camera connected to cam1 port.

USB needs to be activated by adding
"dtoverlay=dwc2,dr_mode=host" to the config.txt file.

Any more tests required?

[the-nicolas]

Here is also a link to the pixhawk standard pinout:
https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf

It would be good to follow this standard for telem (uart) and i2c. For USB I would also use the same pinout as for i2c/can, so at least voltages are on the same pins and you don't smoke something when connecting the wrong cable...

[harlab]

Ok, thanks for your inputs. It will take a time to implement all these features, especially taking into account that some of those need prototyping, but in general we have plans for all of that anyways. Will share some preliminary layout as soon as we have it

Only have to note here that last time I looked at CM4 datasheet, it was missing recommended operational conditions wrt 5V tolerances, but there can be small soldering jumper to switch between 5.0V and 5.1V

[the-nicolas]

@harlab Thanks a lot. Looking forward for it and hope you make good progress.

Regarding the input voltage I also can't find any information. The mentioned 5.1-5.2V relate more to the normal Rpis. I guess they have some diod for protection which costs some voltage, that's why the voltage should a bit higher.

Regarding input voltage: it would also be good to have some protection that the gpios accept 5v as input voltage. Or does the cm has that already?

[harlab]

@the-nicolas, Pi4B input has no protection series diode and voltage goes directly to PMIC, so 5.1-5.2 probably would be fine as well.

All Raspberry Pi models are not 5V tolerant. UART should be no problem, but i2c... it'd be better if periphery is missing pullups and SDA/SCL lines tied by CM4 to 3.3V

[Consti10]

Can you give us a date when the original version is going to be available for us to buy / test with ?

[harlab]

CM4Ext Nano is in production now and expected to be on sale mid-March

[gabyavra]

CM4Ext Nano is in production now and expected to be on sale mid-March

Is it going to ship from Europe or China?

[harlab]

Is it going to ship from Europe or China?

Ships from Europe Good news here

[howels]

Any update yet? Would like to order.

[harlab]

Hi, @howels
CM4Ext Nano is manufactured and on a way for testing and packaging

[wqq3000]

我可以确认 OpenHD 2.0.8 Buster 在 CM4 + IO 板上工作得很好。从 eMMC 启动。空中和地面。我在两侧使用了一个 usb-ac56 和连接到 cam1 端口的 arducam imx477mini csi 相机。

USB 需要通过
在 config.txt 文件中添加“dtoverlay=dwc2,dr_mode=host”来激活。

还需要什么测试吗？
ar9271 90% can't start, is there a solution?thank you