In the past I've considered making and selling a cheaper version. Aside from lack of time (or motivation), one thing which discouraged me is that I would feel bad "undercutting" someone selling open hardware.
I understand the feedback about the price. When I created the original TinyPilot,[0] I wanted a low-priced alternative to the $600 KVM over IP options I was seeing, and now I sell my devices for $400-500/unit.
The thing that's tough about selling hardware is that it seems easy to produce a few units cheaply, but creating a sustainable business for it, the costs add up. You have to fulfill orders, provide support when there are delivery issues, provide support when the customer has trouble understanding how to connect to a device on their local network. And there's certification, stockpiling components so you don't run out of stock, managing inventory from many different vendors.
TinyPilot became profitable in 2023, but for the first 2.5 years, we were operating at a loss. [1]
Also, small correction: no KVM over IP vendor is really selling open hardware. The part that's open is the software. I haven't seen any vendors publish their hardware schematics. It's expensive to create PCBs, and it's not like open-source software where you can hope to get useful external contributions.
[0] https://tinypilotkvm.com/blog/build-a-kvm-over-ip-under-100
[1] https://mtlynch.io/retrospectives/2023/10/#tinypilothttpstin...
But of course github stars and positive reviews won't pay our bills. So it totally makes sense to charge what you are charging for your product. You deserve it, and you're clearly putting in hard and honest work. If and when I need a KVM I will 100% be reaching for a TinyPilot.
But I personally don't care about support, the enclosure can be 3d printed or some cheap plastic box, if sold as DIY kit it would save assembly costs and avoid need for certification and so on. I think there is a small market for homelabers like myself who would pay maybe $100-150 for a simpler product.
And congrats on being profitable.
Is it possible to order current revision of TinyPilot for someone in a remote location and connect to it on arrival through some managed service - without going through all the hoops of helping end user with setting up some form of reverse shell (e.g. either meshcentral or openvpn/wireguard for webinterface)?
It may seem overpriced when compared to collecting all of the pieces and putting them together for yourself, but the person trying to do this as a business has to make a big investment in up front purchasing as well as labor to get them all together and shipped out. It quickly reaches a point where doing it for an “undercutting” level price doesn’t justify the risk and effort.
An arm soc is probably $100. So break even is maybe $200 per day getting the thing working. Thus should buy the thing, unless you particularly enjoy the construction process more than whatever else you could spend the weekend doing.
The posted profit over time figures suggests the above back of envelope is rather optimistic, so there's a non-zero risk that after the weekend the thing wouldn't work.
(and thus I've learned that the UK distributor is in Germany with possible brexit/VAT hazards, but hopefully it'll turn up at some point)
They don't seem to directly support the upstream project, and I believe they may have even forked some of the software from PiKVM and TinyPilot both and may or may not have provided proper attribution/recognition... so take that as you may.
This project is a full-time job for an entire development and support team, and it's a way to keep the software open. For this money you get excellent hardware, software without any restrictions and a huge number of features. We also have a production-grade support: if you find a bug, it will be fixed quickly, and if the device fails due to a defect, we will quickly replace it.
In fact, we have developed and support all the key components of the KVM stack for Linux - the video server, kernel patches, and so on, which is also used by our competitors, like TinyPilot. But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time.
In addition, the production of large quantities of iron is quite expensive. Each device must be assembled, tested, packaged, and so on. When you do some small project, you can do it yourself, but in a large batch it inevitably has to be delegated to the factory, where each operation costs a certain amount of money.
In summary, that's where the price comes from: software, support, development, people.
This is true and is a fundamental difference between PiKVM and TinyPilot.
TinyPilot charges a yearly subscription for customer support and software updates because those things have ongoing costs.
I don't think small businesses can realistically promise customers free support and updates for life. It may work in the short term, but at a certain point, it's not sustainable for a vendor to spend their limited support and dev resources on customers who purchased hardware five years ago and will never pay the vendor another dime.
usb splitter $9 - https://www.amazon.com/dp/B08C5FWQND
usb power blocker $7 - https://www.amazon.com/dp/B094FYL9QT
hdmi-csi2 adapter $32 - https://www.amazon.com/dp/B09GY9M9BX
atx power control looks less off-the-shelf
As a potential customer, I feel bad you feel that way.
Have a few devices that keep conflicting with one another and acquiring the connection to my bluetooth headset. I have to go through the hassle of navigating to the offending device's bluetooth settings, disconnect it, go to my desired device's settings (which, although it reports it is connected, doesn't actually produce any sound), disconnect it, then reconnect it. Each time.
I'd rather have them all stay connected (maybe one cheap dongle per endpoint) to my rpi and then route to the intended destination with just a press of a physical toggle/key/slider etc, or via phone app.
Additionally would like to be able to simultaneously mix multiple audio sources to the one headset.. oh, and all of this with no latency overhead, please :)
I just tried, and I'm able to pair both my Macbook Pro and iPhone to my Linux desktop PC. The PC has Kensington Bluetooth USB dongle. Both the MBP and iPhone can simultaneously play audio over Bluetooth and I can route the incoming audio to a pair of wired headphones. The volume of each stream is independently adjustable via `pavucontrol`.
I also tried pairing a bluetooth headset, but the audio was choppy. Maybe too much bandwidth for 3 devices streaming audio at once? Maybe another dongle would work?
Note that at one point I was experimenting with receiving BT audio on my PC. I can't remember the exact set of configuration changes needed to make this work (if any -- it might've worked out of the box). But the stack is BlueZ + Pipewire on Archlinux.
Pipewire (and Pulse) have a lot of modules and config knobs. Might be possible to get auto-switch working too. They also expose a D-Bus interface, so control from some sort of e.g. Python webapp from your phone is likely.
The problem was that I had no clue where to even begin to make this setup persistent so I could eventually put it all on a GUI-less RPi, so I gave up.
Try reconnecting it. I have the same problem with my headset sometimes and reconnecting fixes it. My best guess is the implementation of the two Bluetooth modules don't play nice with each other. I have no troubles connecting to a different pc.
Rolls MX51S Mini Mix 2 Four-Channel Mixer https://a.co/d/48XLqLi
USB to RCA https://a.co/d/iam01Xj
Bluetooth 5.0 Transmitter 3-in-1 https://a.co/d/47TuAMn
The bad news is the latency which is about 200ms regularly and 40ms with APT Low Latency or 80ms with APT Adaptive. If you go BT > BT RX > BT TX > BT this might be doubled. Both devices will also need to support the same codes and only newer devices support APT Adaptive.
Wanted to have pulseaudio/alsa dmix handling multiple streams/mixing them out with a help of dedicated hardware BT/DAC-ADC-BT path, with a goal to have smart handling of voice calls over music on the go, fake 5.1 in the room, and a voice enhancer / fast rewind for call streams..
Then, Volumio took enough of the raspberry-based hifi market (despite having no bluetooth support, lol) that I've declared these plans no-go as investing in this solely for fun wasn't that enticing, compared to just getting a spare set of equipment to separate work/home audio.
The cheapest one I found for a three monitor DP setup was ~$500 (Star Tech).
Not the cheapest, but very good.
My solution was:
-BIOS: auto-power on when power is connected
-Smart power plugs on important computers
-AnyDesk for software on all machines, with unattended password set (connectable even at login screen, less annoying for licenses than Teamviewer)
-(Optional) my own WoL sending / restarting / RAT program for all the machines too
-(Optional) Parsec also installed, to allow remote desktop good enough latency/control wise for actually gaming remotely (which I often did!)
This way, I will never be stuck in a situation that I can't access a machine that I'm away from, unless it's one of those without a smartplug and has somehow hard crashed. Costs less than 20€ per machine. I've NEVER needed to access the bios or similar remotely.
I've recently played around with a lot of SBC's and have a spare capture card and cheaper sbc's that could work as OTG keyboards. Might end up building a crappy version of one of these for fun
Unless you mean a separate internet connection entirely?
For each connected device you need a dongle, which is what will plug into the display and usb ports of the server.
The TLDR is that manufactures don't follow specs as closely as you'd think, and as a KVM you have to handle the bugs of thousands of different manufactures for both upstream and downstream devices.
anywhoo for those who never and are curious the lag is almost entirely on the return channel, processing the hdmi signal and getting it back to client side. it is definatley useable for programming but certainly not for any interactive graphics or gaming. i'm wondering if since its a processing bottneck if overclocking the pi would speed it up a bit... it seems to idle at around %20 usage as per the little display.
To save money, I have a switch inside of my machines and have the serial console Pi on an IPv6 address. Having a fully up-to-date, modern OS makes a world of difference.
1. https://www.direktronik.se/direktronik/natverk/kvm-switchare...
I wish the Asrock Rack boards would have a similar letsencrypt integration.
