Author: Davide

Sometimes you have to make a choice you cannot know for certain is the right one.

I’ve decided to issue refunds for the preorders and to halt product development. I do not believe that the small niche this product is going after will be enough to sustain it in the medium to long term.

The technology is solid and so is the product. I hope it will keep on living in the shadows due to some IP licensing deals, but I just don’t see the commercial, user-facing version as a viable business model. I applaud companies and designers that somehow managed to make it work for them, and I hope they are not secretly loosing money.

I’m very grateful to everyone that supported me during those years, and I’m sorry I’ve let you down.

It was a pleasure sharing this dream with you.

Davide

Today marks an important moment in the development of this product, as today is the day I committed to manufacturing the batch. There is no going back now.

I’ve just finished paying a few key suppliers for some long lead time components. One of them is a camera. Here is its story.

This begins in 2015, when I first sent an email to an OnSemi salesperson, or maybe I filled out a form on its website, I can’t remember. I was reaching out to several possible suppliers at the time as I was first dipping my toes into this venture. Most of them never got back to me. As a tiny fish with no experience you aren’t worth anything to them, so when I never heard back I thought that was it. OnSemi had recently acquired Aptina, pretty much one of two camera sensors manufacturers in the world. The other is OmniVision and those guys dealt in even higher volumes (I will pretend Sony doesn’t exists as that’s a different planet entirely).

Then, one day, two months later, as I was checking my emails, bored in a basement classroom in DIT (such was my surprise I still remember the moment clearly), I got an email from OnSemi asking to sign an NDA for accessing the Image Sensor Portal, that is pretty much all of the datasheets, reference manuals, registers, etc. for the Aptina lineup. I thanked the person that emailed me many many many times pretending like I was cool and I could do without them, sent over the signed NDA (still uncertain as to whatever I would have heard from the guy ever again), and a few days later I had access to the documents.

I could now develop using Aptina sensors. Cool, right? Well… Let’s say expensive is a better term.

The Aptina chips I ended up using for the 1.3 GHz batch were the AR0132, a 720p HDR sensor and the AP0100, an Image Signal Processor, whose job is pretty much taking the video out of the camera and making it likeable to the human eye with subtle details like white balancing. Some hardware limitations I won’t get into didn’t allow me to do white balancing inside the chip receiving that video stream.

Those chips were around $30 and $13 each (source: octopart), so $43 going down the drain in camera chips alone. That doesn’t include connector, cable*, board, assembly, enclosure, lenses. Let’s leave it at expensive and let’s say that camera was $80 a piece in cost.

Now, if you are planning on spending more money and time in making a 2.4 GHz version of your product, you better have a plan to lower that cost. The plan included begging OmniVision, whose sensors are cheaper, and did result in a signed NDA with them as well (Yippee!), but this is not where this story is going. The HDR sensor here is still from OnSemi.

The winner today is called AS0140, which is a single chip solution with sensor and processor, all in one single chip. It’s mostly used as a rear view camera for high end vehicles, so you can thank people with expensive cars for this chip’s existence.

Now, as you can imagine, people making cars don’t make them 10 at the time so the minimum order quantity for this chip last year was 2970 units. Digikey lists them at $15 a piece, so that’s a cool $45k if you want to use that camera. Reaching out to my sales contact didn’t help and no one had it in stock in lower quantities.

3k units is way too high and I couldn’t afford spending 45k in expensive silicon, so that was it. Again. Or so I thought, because I did just place an order for it with a supplier that had it in stock and was ok with selling to a mere mortal, so there was a way, one way that didn’t include any of the simpler channels, that is not listed on octopart and didn’t pass through Asia. The answer was cold emailing people.

I guess not giving up pays off, some times. But only some times.

The rest of the story was as simple as purchasing a $300 development board to add on top of something else you paid $780 for, and you are all set.

Here is what that looks like:

*The KEL microcoaxial camera cable was something ridiculous like $10 a piece and 3 months in lead time, which they didn’t even met.

I keep getting this. This isn’t designed for ultra long range FPV. Sure, it’s so good that as shown, it can do that. But that’s not what this is all about.

This product is about having an ultra low latency, very reliable 2.4 GHz video link with RC and Mavlink. The applications?

• Controlling aerial cinematography drones where you can switch between the HDMI camera and our own custom (piloting) camera, or if you want, two HDMI cameras (why would you do that? Well, now you can).
  • The HDMI input board cable is so long and flexible it will be able to go around a stabilised gimbal without interfering with it. It will be a breeze. Wait for it to be shown here.
• The big majority of the “zero delay” broadcast market, where the average product is a $3000 metal brick with a 300-foot range and they forget to tell you yes, transmission latency is 1 milliseconds instead of our 25 milliseconds but camera latency is usually at least 100 ms, so you are paying an extra  $2500 to have 101 ms instead of 125 ms worth of latency. That has to be the best marketing ever.
• Surveying fields and running YOLO (You Only Look Once) on the ground HDMI out (yes, some crazy people that are maybe reading actually play with this).
• Sure, FPV. Anything but ultra crazy fast drone racing where people actually notice a 30 vs 45 ms latency difference. Good luck cracking that nut.
• ???. You can help me fill in this field in the comments because honestly, there are so many of them.

Closer range tests are coming but I’m extremely busy working full time on this thing so that I can show you renderings of the product and convince you to finally put in that preorder.

First off, no reason to worry. This was expected and planned for as explained in the “Why preorders and why now” post.

I guess those preorders must be even so slightly successful for PayPal to finally freeze the account. This morning I woke up to:

One of the steps required is proof the orders actually shipped. Funny thing is, this didn’t happen last time as the product was in stock, so either a human or a ML algorithm correctly decided we are running preorders.

As you can imagine I can’t provide proof of shipment for a product that didn’t ship, so I can’t unfreeze the funds, so PayPal is going to be my long term bank deposit I didn’t ask for for a while now.

The next step is for PayPal to freeze deposits as well.

This will happen either in 40 days “or if we notice additional changes in your account activity”, which I guess means more preorders.

In other words, the PayPal payment option is fading and doing so fast. If you want to pay using that option the window to do so is closing. If you want to make sure I can’t access your money before shipment, that is also the way to go.

Why release a single video when you can release two at the same time?
Both are showing the system working using dipoles – no high gain directional antennas increasing range!

A word of advice: the 700mW video was filmed with out of focus lenses. A real shame, so make sure to watch both of them!

The 700mW video is is the only one where the system is far away enough to failsafe (trading video quality for range moving to a narrower bandwidth), so editing focused on showing that behaviour.

There is a lot that can be worked on via software changes, this is just setting some limits on performances to be expected but framerate and recovery/general behaviour will keep on improving. This is just the result after a few times out of the lab, after all.

100mW:

700mW:

I’m opening preorders for the 2.4 GHz version of the system. In doing so, I want to explain why they are the only way forward and give some background on what is needed for those numbers to work out.

First off, fpv.blue has been loosing money since its inception. I used funding from another profitable endeavour of mine, a website, in order to bootstrap it. Over the years this other business slowly decayed and I’m not in a position where I can throw money at solving a problem I have at heart anymore, .blue needs to become profitable or be closed down.

Fortunately, I finally consider the technical aspect of the problem solved, with everything else being the only remaining minority issue. This is ironic, as most hardware startups fail being unable to manage cashflow or capital, not because they can’t solve the technical problem. The technical aspect is supposed to be “simple”. This one really wasn’t, it’s a miracle I got this far. Which leads me to the first answer:

Why now? Because it’s working

I never wanted to commit to releasing a product, even less so taking in customer’s money, before knowing for certain the thing to be actually real. You can think something up in your mind, prototype it, verify every theoretical aspect of it and lab-test it all you want, but there is no replacement for actually going out in the real world and praying. I can finally say this works, and it works well, and it’s insane but my theoretical understanding of the problem was actually matching reality well enough to materialise in a nice product. So it’s done, and working, and I will publish videos showing it. And I can finally open preorders.

Why preorders? Because this is a terrible business

Hardware manufacturing is a walking nightmare. Let’s put aside all of the issues that go into the manufacturing part. Let’s assume a perfect world where you pay some money to get some result and there are no unexpected problems, no delays, nothing out of specs and no one screwing you over. Let’s just talk about the money part of the problem.

Manufacturing requires upfront cash. That is one hell of a big problem, but here are another two compounding it:

• You need big volumes, otherwise the price will be too high and people won’t be interested. To solve it, you need a lot of upfront cash.
• Due to how online payment systems work you can’t use that money for manufacturing as in most cases it is only available after shipping. In solving this, no amount of (customer) upfront cash will help you.

Now some numbers. For the sake of argument, let’s assume:

• 100k as real fixed costs so far, like development boards and tools
• 30k salary per year times the last year of development, let’s ignore the time before it and how I could make more walking into any job
• 20k as additional running costs per year

So, as a gentle assumption, let’s say that if .blue is to break even within a year it has to make profits of 200k. (costs so far + costs for the next year).

At a 20% margin and 450 per unit, that is more than 2k units. There is no market for that. Let’s scale back, let’s say the fixed costs so far are something I should forget about and let’s consider the cost during last year and the next year, 100k. That’s 1k units in one year, 3 per day. A big nope still.

Let’s keep scaling back then. Let’s only consider the running cost from today onwards. 50k per year. Let’s assume I can keep doing everything myself without going insane. That’s still 500 units, that is a very, very, very positive proposition and it is unlikely to happen still.

So this is where I’m at.

I need a price low enough to be interesting. Volumes high enough I get better deals on manufacturing and hopefully get a slightly better margin than 20%. And a way to handle a frozen paypal/credit card account, that is going to cut on the margin for sure.

There aren’t many ways to come out ahead in this situation and the only one I see is good reception for this batch of preorders. Because of the volumes problem, I can’t rest my hope in a future batch. This isn’t to say “You need to preorder today without even a video of the system working”. This is to explain, as clearly as I can and even if at the bottom of a long blog post just a few will read, there is a very good possibility this product doesn’t materialise merely because the numbers aren’t good enough to make anything work.

So, if you want this product to succeed, please preorder as soon as you see a video online of the system working to your satisfaction. I will make sure to deliver that.

Just a quick update for people strolling by this blog for updates. The new transmitter board is ready, I found and fixed the problems I believe caused the glitches during the last test and can’t wait to test it all… But it’s been raining for a week now in Northern Italy and it will keep on pouring with no break for at least another one. The first sunny day should be next Monday.

Where to start. The tl;dr is more delays, as the only prototype I had was lost yesterday on a mountain ridge and there is absolutely no way to find it.

The crashed happened after 1) The video transmitter software crashed (in a way that never happened before during development – I was so confident I didn’t have a watchdog enabled) and 2) RTL failed to work, even though I had tested it the day before.

The relatively good news is that I have a ground recording of the event I can share. It’s nothing to be proud of, but it’s the only video I have at the moment as I also discovered my external ground recorder will happily overwrite files saved during the previous boot. I feel like I keep blaming things on others, like having lost the flight from two days before (where at least the camera was showing less vibrations) but that’s not my intention.

Anyway, the video shows the system working at 10mW with omni antennas (2 dBi on the drone, 5 dBi on the ground) and reaching 600 meters at full data rate before decreasing it gradually until the software crash at 1.7 km. In theory the system still had ways to go as the sensitivity limit wasn’t reached, but I can’t say for sure what that would have looked like, yet, as I’m not giving up.

I will leave you with a narrated video of the test.

I’ve now ordered a new transmitter PCB that should be here on Saturday if it’s not delayed at the factory. If everything else goes perfectly well I should be up in the air on Sunday for the next tests, that are 100 mW, 1 W and finally 1 W with yagi antennas.

Welcome to the first update in over a year. Topics covered:

• Why I haven’t been more forthcoming about development status.
• Development hell and an example of what the end of December looked like.
• Specifications for fpv.blue’s 2.4 GHz version.
• Timeline for the materialisation of the aforementioned product.

As a small introduction for people out of the loop, fpv.blue’s first version was on sale for a very short period at the end of 2017. No sale has been made since then and all of the efforts shifted into designing a second revision working on 2.4 GHz. By all of the effort I’m talking about a single person, the underwritten, working full-time starting from June 2018, which is 6 months and counting.

The Apology

fpv.red – I mean, .blue, was first announced as little more than a proof of concept – one that could fly, but nothing more than a proof of concept nevertheless. I had very little experience with electronics design and manufacturing and was relaying on the help of an external freelancer to help me with it. I had to learn how to solder those tiny resistors the hard way, damaging expensive boards. I barely knew anything about embedded software development and there too, employed external help for part of the codebase as I couldn’t fathom having enough time for it all (the initial code for the STM32F746 on fpv.blue’s first batch wasn’t written by me, even though I spent a lot of time on it before shipment).

All of this brought me to shipping a first batch in late 2017, in an economically unsustainable manner and with a technical result I’m not proud of. Learning from the wise people I had employed, I then started doing everything myself. I’m a perfectionist, so I had to let go from time to time, but I’m glad I went this route as I now have a 360 degrees view on the product and can in some of the cases work much more efficiently then when I had to coordinate with other people not physically around me. The end result of all of this integration, in my humble opinion, is phenomenal.

Anyway. Back to us. The way I had conducted .blue had to stop and did so just after shipping the first batch. I patiently collected my ideas for a second revision and waited until the end of my Computer Engineering degree at Trinity College Dublin in June of this year before jumping into developing FPV hardware full time again.

This time, I promised to myself, I wouldn’t have engaged prospective customers before I myself had the ability to commit to performances and timeline. I then went silent and had to watch people wondering if the project was dead, answering to them in my inbox, but seldomly doing so publicly.

A story of the last couple of weeks of December

As December arrived hardware development was pretty much completed and focus shifted on to software. I had a flight booked for the 24th of December, when I was planning on leaving for my parent’s home where I could test the results of my efforts in the real world. A few days before that, when it became clear I couldn’t make it, I moved my flight to the last day of December. The 24th of December would have ended up being the first day a video frame was making its way through the system, and I was going to spend Christmas Day and New Year’s Eve working. After that, a few hours worth of scheduled work turned into a week of kernel hacking (underperforming DMA hiccups and insane workarounds), the pattern repeated itself, and I finally moved my flight to the 4th of January.

Yesterday night, a bad move on a very messy workbench fried a voltage rail on the receiver and with it all of the associated chips. Magic smoke, old friend, we meet again. With DigiKey being closed for holidays on the first day of the year there was simply no way I could have gotten a replacement here before leaving.

I gave up.

I plan on taking advantage of my flight tickets to go see my family, and I will be back in the office on the 11th. I booked another flight this morning, from the 26th of January to the 1st of February and I cannot foresee any set of events where I don’t have data on the performance of the system by the time I come back.

.blue’s 2.4 GHz specifications

This is what the system is currently designed to do and to the best of my knowledge, it is true and accurate. It won’t be perfectly matching the product that is going to be actually released, but as of now, I have no reason to doubt any of this.

• 2.4 GHz: Worldwide, legal operation.
• Video, RC control and telemetry over the same radio frequency link. You will be able to stick the receiver at the back of your RC Radio and have it transmit the RC signal to the video transmitter.
• State of the art sensitivity, up to -105 dBm for video (-110 dBm for control) in ultra long range mode. In full data bandwidth mode, video sensitivity is -95 dBm or better.  The system dynamically adjusts the link budget according to interference to provide the best tradeoff of quality and range.
• 1080p @ 30 fps. This mode will be available both via the HDMI input and via a custom camera. The standard camera will be 720p.
• Two video inputs, switchable in real time and connected with an extremely flexible, user replaceable cable of arbitrary length. The inputs can be two HDMIs, one HDMI and one camera, one FLIR and one custom camera, etc.
• Real receiver diversity employing MRC (Maximal Ratio Combining) and advanced interference rejection.
• Fast interference recovery, as low as 8 ms for a short interference burst.
• Digital audio microphone on the transmitter going to the HDMI output at the receiver.
• Glass to glass latency still at 50 ms or better when without interference, 40 ms or better with blueSync enabled.
• Currently being debated: Analog video output at the receiver.

Target pricing will be of USD/EUR 180 for the transmitter, 260 for the receiver and from 30 to 90 for each video input.

 The next timeline

When I talk about the timeline for the “materialisation of the aforementioned product” I’m trying my best to subtly joke about a topic I find frightening. The last thing I want is to mislead people with wrong timing expectations. The follow is optimistic, but I believe I can do it.

• January 11th – 25th: more software development, reaching a mature level as far as the radio frequency subsystem performances are concerned.
• January 26th-February 1st: real world testing and results.
• Beginning of February: test results publication and opening pre-orders.
• February (2 weeks): receiver’s PCB size shrink and integration, sent for manufacturing.
• February (1 week): video input subsystem/cable prototyping, required for the following transmitter PCB shrink
• February (1 week) and March (1 week): transmitter HDI PCB shrink, prototype sent for manufacturing.
• March (1 week): final receiver bringup. If everything green lights, begin bigger scale manufacturing of the receiver for the pre-orders.
• March (1 week) final transmitter bringup. Just as above, if nothing goes poorly the final HDI PCBs can be sent for manufacturing.

Allow one month for manufacturing and more time for timeline slips and you get to the end of April 2019 for the first shipped preorders.

Thanks for reading.

February Update:

Unfortunately due to personal reasons I couldn’t work as much as I thought I could and the timeline above is now postponed by four weeks. I hope to have real world test results by the end of February.

February 28th Update:

As usual, I’m late. The system is finished, just putting some finishing touches on it this weekend then booking a last minute flight next week to go somewhere it can be tested long range. Between that and the time it takes to edit/upload the video the 15th of March sounds reasonable? That’s the internal deadline I will try to make.

March 7th Update: 

Flight booked for the 13th of March. The machine learning algorithm deciding ticket prices made me an offer I couldn’t refuse.

Testing from up in the sky is complicated (especially if you don’t live in the middle of nowhere), so this is a ground propagation test, from a small hill:

Conditions:

• Tx antenna: 2 dBi vee
• Rx antenna: 3 dBi dipole
• Frequency with the lowest noise floor selected (there in an on board spectrum analyser to help you with that!)
• Tx power: 15 dBm (32 mW)
• Line of sight with the transmitter: most likely not the case. Most of the received signal was likely reflections from nearby objects.

Results:

A solid 5 Mbps stream, as long as the 3 dBi receiving antenna was kept in the same position, a few cm from the receiver. That’s one of the reasons why we are saying we didn’t have line of sight. Unfortunately the green field to the right of our mark on the map was cultivated and difficult to access.

As theory suggests, lowering bandwidth to 2 MHz let us lower transmitting power to 10 dBm (10 mW) without losing signal.

Changing frequency to ones with a higher noise floor didn’t give us those nice results, so make sure you select a good frequency before flying!