search

harlab / CM4Ext_Nano

Smallest, yet feature rich baseboard for Raspberry Pi Compute Module 4
152 stars 10 forks source link

CM4Ext Nano OpenHD Edition? #3

Open harlab opened 3 years ago

harlab commented 3 years ago

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:

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

Consti10 commented 3 years ago

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 commented 3 years ago

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

CopterGUI commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago
  1. 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.

  1. 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

my 2 cents:

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

harlab commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

Here is a link to some grounstation builds:

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

harlab commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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:

Now questions:

howels commented 3 years ago

Sorry for the confusing mention. Watching this thread with interest :grin:

the-nicolas commented 3 years ago

Alright ;)

Definitely option 2:

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Good Morning everybody, Nice to see the progress :)

Some more notes from my side:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

harlab commented 3 years ago

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

gabyavra commented 3 years ago

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

Is it going to ship from Europe or China?

harlab commented 3 years ago

Is it going to ship from Europe or China?

Ships from Europe Good news here

howels commented 3 years ago

Any update yet? Would like to order.

harlab commented 3 years ago

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

wqq3000 commented 3 years ago

我可以确认 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