CM4Ext_Nano
CM4Ext_Nano copied to clipboard
harlab
CM4Ext Nano OpenHD Edition?
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.
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.
- 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
- 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 ?)
- Smaller usb connector(s) than "full usb connectors" are preferred.
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
Hi @Consti10, good to hear that developers nearby available. That would make testing easier when hardware involved.
- 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.
- 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.
- I get your point regarding connector type. Smaller is better and something on vibration resistant side, rather that hot-gluing)
- 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.
- 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.
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.
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
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).
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:
- Users can re-use their existing wifi adapters (really important)
- USB wifi adapters are well tested and available everyhwere, PCIe cards are not
- USB can work over distance
- 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
@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):
- 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.
- USB WiFi + USB camera on USB3.0 controller via PCIe. Can be tested on regular RPi4B.
- PCIe WiFi + USB camera on native SoC USB2.0 port. Can be tested on CMIO board with PCIe to mPCIe adapter and WiFi card.
- 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?
@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 ?
@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
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 ?
I want to give my 2 cents and vote for option 2.
Because:
-
no tested pci WiFi cards available. And people will want to use their old cards.
-
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.
-
option4 sound like a lot of work and money
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 :)
@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
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.
Here is a link to some grounstation builds:
https://discuss.openhdfpv.com/c/custom-tx-aio
@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
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.
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
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
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.
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...
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.
@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
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...
- I2c and UART should definitely use already soldered connectors. JST-GH seems like a good chice.
- 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.
@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?