Thanks for sending me the prototype to test; besides the labeling issue, and the fact that I accidentally fried one of the fan power cables (thought I'd burnt up the whole unit!) when I first put it together, it's already a great product. I hope you sell many more thousands, and keep improving the experience!
Same here, I hope you sell a LOT of these, because it's still a bit expensive for my home lab stuff and I want you to benefit from economies of scale so I can buy a hat for around sixty dollars.
It says PiKVM has support to press power buttons etc. Does PC hardware also have means for health checks, to determine if this is needed? Could be a useful feature
What open-hardware Raspberry Pi alternative would you be using with this then?
After all, hardly any point of having a open-hardware HAT if you connect it to a closed-hardware Raspberry Pi. Even if the full schematics etc were available, the processor on the Pi is anything but open.
General microcontroller questions if you don't mind.
Lets say that I prototype something on dev board like something from Raspberry Pi, or ones from STM. Now I want to do a full product, (like the Tiny Pilot) with the microprocessor on a custom PCB board with just the necessary hardware.
I understand that you have to design the schematic and then get the PCB layout done, but in terms of figuring out which pins to connect, is it just a matter of figuring it out from the microcontroller manual? Additionally, how do you end up programming the microcontrollers, do you have to have a separate programmer since you don't have all the stuff on the dev board?
TinyPilot runs on the Raspberry Pi 4B, so I haven't made my own custom board yet.
The Voyager 2 will use custom PCBs for the HAT, but it will still be on top of the Pi.
In the next iteration, I'd like to use the Pi Compute Module to migrate to my own custom board, but I'll need to work with an EE firm on that, since I'm not knowledgeable enough about EE for that kind of project.
By the way, does Voyager 2 have its own CSI bridge, or are you planning to mount a ready-made module from Geekworm or another company next to your HAT?
All existing CSI bridges that you have used so far have two very serious problems: they do not work with audio capture and due to HDMI backpowering, your Raspberry may stop booting until you physically disconnect the cable. Backpowering is especially common when using KVM switches and some HDMI converters.
Both of these problems are solved on v3 HAT, thanks to our CSI bridge design. Are you planning to solve these problems? Just interesting :)
Voyager 2 uses the C779 bridge. I've heard of failure to boot when users chain TinyPilot to the AIMOS KVM, but I've never gotten reports of this being a problem otherwise.
There's no audio support, and audio would be a nice-to-have, but it's not my top priority at the moment.
I'd like to integrate the TC358743 onto the HAT itself, but Toshiba's got a huge lead time on orders right now.
> Lets say that I prototype something on dev board like something from Raspberry Pi, or ones from STM.
Worth noting that your typical STM32 MCU is quite different class of device compared to the Broadcom SoC on a RPi. From a architectural point of view, the big difference is that MCUs typically have both flash and ram integrated in the package, while SoC requires external ram and flash. Designing PCB for high-speed DDR memory is not trivial. Modern SoCs come in high-density BGA packages usually sporting close to thousand pins (or more!), while MCUs usually come in more easy to work with packages with order of magnitude less pins.
Specifically the Broadcom chip in current RPis is custom made and not generally available.
> I understand that you have to design the schematic and then get the PCB layout done, but in terms of figuring out which pins to connect, is it just a matter of figuring it out from the microcontroller manual?
yes. if you're using ST parts i suggest using their CubeMX tool, if only to figure out pin assignment. makes it way smoother.
i've seen multiple real projects with real engineers who should get this shit right screw up pin assignment.
also seen them just... not read the data sheet. i don't understand how they expected the board to work, but, it happened.
> is it just a matter of figuring it out from the microcontroller manual?
pretty much, you might end up tweaking which pins you use when designing the pcb because the one on the other side of the chip is just as good, but it simplifies the routing and layout of the board significantly.
I started work on that earlier this year, but I paused it to focus on PoE. That work is almost done, so I should be able to revisit ATX early next year.
The challenge is more on the UX side. It's not that hard to connect the Pi's GPIO pins to a motherboard's ATX pins, but I want to do it in a way so that it minimizes the amount of nitty-gritty pin-matching that the user has to do to connect it correctly.
>And do you listen to any of these Covenant Network radio stations that are now under TinyPilot’s control?
I don't think they'll reach me out here in Massachusetts, but if I'm in the midwest, I'll check 'em out.
"Keyboard, Video, Mouse" is what the acronym means for anyone wondering. Some IT workers will have one at their desk to switch a single set of monitors, keyboards and mice between multiple computers.
In this context, however, there's an additional expectation that these devices make this happen over a network, so that you can handle things like BIOS configuration fully remotely.
> so that you can handle things like BIOS configuration fully remotely.
Yeah, the important distinction here is that these devices somewhat fulfill the role of a standalone IPMI[1] device. IPMI is typically built into server motherboard (SuperMicro) which allows an administrator to reboot a machine or configure BIOS over a network. Your typical KVM does not feature this.
However, where these lack is that they still require a video card. IPMI built into a motherboard can run on an entirely headless system.
There are also commercial versions of this, such as the Lantronix Spider KVM over IP[2]
Good to note—I should at least in the video have a little text overlay that shows 'KVM = Keyboard Video Mouse'. You forget sometimes how acronym-laden our industry is, and even the ones you find most basic... better to spell it out for someone who might not operate in the same area.
It's more important that one learns what a KVM is rather than what the letters stand for. Like you don't need to know what laser stands for to know what a laser is.
Edit: I say these here mainly because expanded out, the title says "Raspberry Pi 'Keyboard Video Mouse's Compared". That still means nothing to someone who doesn't know what a KVM is (actually makes it sound like HID devices specifically made for the Pi).
If there was a rpi hat that had multiple connections I would probably use it, a $300 avocent 24 port KVM w/ html5 interface is much more cost effective than 24 pikvms, etc.
My plan is to connect a single pi-kvm to the aging Avocent in my homelab rack. The Avocent can connect to dozens of devices, but the IP interface for it is old and unreliable. Hopefully the pi-KVM will make that experience painless.
Maybe for some context - although Jeff Geerling does provide it too in his video - most 'server' motherboards have build-in KVM.
I will make the bet that build-in KVM is more responsive and those interfaces are now HTML5 based, so no nasty Java applet stuff.
Motherboards / servers with KVM will consume around 8-10 watt extra, even when powered off, as the KVM solution is basically a tiny computer running Linux + proprietary software, soldered on the motherboard.
Motherboards with KVM support also support IPMI or redfish for remote management. For instance: I use IPMI to force a physical machine to PXE-boot into an automated installer, to provision the OS.
For some more context why such a device is desirable:
Mainboard-built-in KVMs provided by server vendors are usually buggy as hell closed-source horrors, with regular full-compromise holes that make running them over the Internet a complete gamble.
This is why open-source KVMs that are just as secure as other normal Linux servers, and auto-upgradable, are very desirable.
I think the main use case are home and maybe small-business servers which generally aren't built with actual server hardware. Just look at the rack in his video which was basically just a bunch of desktop PCs on their side.
Jeff Geerling just writes "including BIOS/UEFI". In my extremely limited experience without deep insight it works with some computers while on others the BIOS screens remain black (while the Linux console works correctly). We got it for BIOS work, but that plan did not really work out.
I wanted to implement a KVM on my pi (a while back). I had the usb hdmi capture dongle. What prevented my from finishing the project was getting power in and usb out on the pi connector.
It required a custom cable that I didn't want to build myself. Are cables of this type more readily available now?
There are a couple of vendors (including me[0]) that offer a circuit board that splits the Pi's USB-C port into separate data and power ports with reverse current protection.
There are cables that do the same thing, but they don't provide reverse current protection. If there's a voltage difference between the USB port on your target system and the PSU feeding your Raspberry Pi, you can mess up the system's USB port or damage your Pi.[1]
Then 5V USB-C power supply into the USB-C connector and a USB-A to USB-C cable into the motherboard which had a USB-C port. You could probably also find a USB-A male to male cable and use that if your motherboard doesn't have USB-C.
In my testing and my Dad's, about 100-300ms. Very noticeable, but you kinda get used to it.
You can get it down to sub-100ms using a few hacks, but honestly, this kind of setup is not optimal if you need remote real-time control (e.g. for gaming or video production monitoring).
At least the TinyPilot firmware is Open Source https://github.com/tiny-pilot/tinypilot - i don't know Pi-KVM. And it's a normal RaspberryPi with a debian-based os. So you should be able to just attach an LTE modem via USB and configure it via SSH, right?
Yeah, it should be pretty easy to add an LTE modem. Configuring the networking failover might take some hands on work; it would be a huge boon if either or both projects eventually took care of that for you too. I've had enough experiences where out of band management would be well worth the cost of the cell service that this is something I could see having wide appeal.
For my design I don't want that, because then we're just making it even more complex. There's a VGA encoder I've been working on, I don't recall the chip ID but I found it in the Lantronix Spiders I have. I've been slowly trying to build a HAT with that that pipes into the Pi for everything else.
If I can keep the cost down, I'm aiming for $100/unit, then I think I could sell quite a few. The nearest competitor, the Lantronix Spider, is $300+ if you can even find them.
For my design I don't want that, because then we're just making it even more complex. I'd have to have an HDMI ancoder, then a VGA to HDMI encoder that plugs into that. There's a VGA encoder I've been working on, I don't recall the chip ID but I found it in the Lantronix Spiders I have. I've been slowly trying to build a HAT with that that pipes into the Pi for everything else. Then there is no daisy chaining adapters.
i used to have one of those "hdmi over ethernet" devices which i captured with ffmpeg and used for his purpose. worked well, about 100ms latency for the capture/conversion
// I'm the author ;)