Blogs

New FPV option - FPV HAT for Raspberry Pi

Posted by FernRF on March 26, 2017 at 1:28pm

3689713774?profile=original

Hi all,

I would like to introduce you to an Open Source, low-cost digital FPV video transmission option!

https://www.tindie.com/products/FernTech/fpv-hat-for-raspberry-pi-/

Our FPV HAT for Raspberry Pi 2/3 has these key features:

  • Max. data rate approx. 500 kbit.

  • 433 / 868 / 915 Mhz versions available.

  • Supports AES-256 encryption.

  • Useful for e.g. long-range and/or NLOS SD "analog quality" video links (e.g. 512x288@49fps or 640x360@30fps)

  • OR high-res-but-low-frame rate DIY-surveillance/Robotics/RC/etc. applications

  • OR anything else on a Raspberry Pi that could use a 500kbit wireless UHF one-way data-link!

  • Set of two boards cost 70 USD (Rasberry Pi, antennas, camera etc. not included). In stock. Free Shipping.

The FPV HAT has been developed to enable wireless transmission of hardware encoded h.264 video streams from one Raspberry Pi to another.

The available bandwith is limited to 500 kbit which in turn limits the possible resolution while still maintaining reasonable fps and latency. Video quality is comparable to analog PAL/NTSC video.

But if e.g. your ground rover needs UHF ISM-band video in the 433 Mhz band in order to send the signal through walls or vegetation. Or you want to keep your video stream truly private using hard 256 bit AES encryption, then this might be the board you need!

Also, compared to analog video, bandwith use is very limited at either approx. 300 Khz (2GFSK/300kbit) or approx. 600 Khz (4GFSK/500kbit). User defined frequency offsets in software enables a number of concurrent streams within the respective ISM bands locally.

Please note that this system requires some knowledge of Linux and Raspberry Pi to use. Users may also need to adjust transmit power to comply with local regulations.

FernRF

E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • FernRF April 2, 2017 at 3:14am

    @AndrewZ: Encryption is per-packet. So one bit error will affect the whole packet. But there are many packets per second, so in practice it equals a larger number of "normal" errors which the h.264 decoder handles fairly well.

  • Andrew Zaborowski April 1, 2017 at 3:43pm

    Thanks.  Interesting about the image degradation... I wonder how that works mathematically since a single bit error in the ciphertext is supposed to, on average, affect 50% of the decrypted plaintext, for a good cipher.

  • FernRF April 1, 2017 at 4:09am

    @Andrew: We'll try and give some indication of latency in an upcoming video. Image degrades fairly gracefully, also with encryption enabled.

    FernRF

  • Andrew Zaborowski March 31, 2017 at 5:03pm

    Also by the way will the image quality also degrade in a similar way with encryption enabled?  Or will transmission errors cause a total loss of the frame or blocks of the frame, as could be expected?

  • Andrew Zaborowski March 31, 2017 at 4:13pm

    Some total end-to-end latency figure (glass to glass I think the call it) incl. rapivid and your choice of a display device would be good to have when you get around to benchmarking it.  Thanks!  Look promissing.

  • JeanLeFlambeur March 27, 2017 at 2:29pm

    @FernRF: Thanks a lot for the details. You got me hoping I can revive the 4463 project.

    Can you post some video with the bitrate at this bitrate?

  • FernRF March 27, 2017 at 2:20pm

    @JeanLeFlambeur: If I remember correctly, we use the 128 byte one.

    FernRF

  • FernRF March 27, 2017 at 2:08pm

    @JeanLeFlambeur: Sure. You are right about the specs. And yes, -88dBm is usable. Its just that the SiLabs software has this limit, combined with the fact that we never managed to push it much beyond 500 kbit.

    FernRF

  • JeanLeFlambeur March 27, 2017 at 1:46pm

    @FernRF Actually the datasheet says the max is 500k symbols per second. With 4FSK a symbol is 2 bits so a max rate of 1Mbps. This is well within the specs.

    The RX sensitivity @1Mbps is -88dBm which is very usable.

    Regarding the fifo, I was curious if you used the split 64RX+64TX fifo mode or the combined 128 bytes one - which would make sense in your case as you have unidirectional comms. 

  • FernRF March 27, 2017 at 12:54pm

    @FernRF: Its true that the data sheet says 1 mbit. And the hardware might even support it. But SiLabs configuration software only allows initialization up to 500 kbit. I suspect that the receive sensivity gets so low that it isn't worth it. But if you're up for it, you might design your own initialization bytes and see how it goes ;) These radios are rather flexible and there are other outside-spec possibilities with them.

    Re the extra caps: That was just to be sure that there are enough power on tap.

    FIFO: You mean the on-chip one? yes.

    FernRF

This reply was deleted.