Thread Tools
Oct 19, 2019, 02:22 PM
Registered User
Quote:
Originally Posted by 5zero7rc
Based on the information Fat Shark posted here about the HQ channels using 27mhz with 6mhz separation and the channel numbers from the manual, I have updated my FPV Frequency Chart to include that information. Hope it helps people understand where they might run into interference issues. I made a complete guess as to how wide the LQ bandwidth is. If no one is going to use LQ anyway, I might just remove that part.
BIG THANKS

Will use this when racing against some old school analogue quads tomorrow hopefully.
Sign up now
to remove ads between posts
Oct 19, 2019, 03:59 PM
We are not men, we are DEVO 7e
xanuser's Avatar
hey its not a bad video, i just could not follow it. no biggie.
Oct 19, 2019, 04:26 PM
Registered User
Quote:
Originally Posted by 5zero7rc
Based on the information Fat Shark posted here about the HQ channels using 27mhz with 6mhz separation and the channel numbers from the manual, I have updated my FPV Frequency Chart to include that information. Hope it helps people understand where they might run into interference issues. I made a complete guess as to how wide the LQ bandwidth is. If no one is going to use LQ anyway, I might just remove that part.
That chart is great. Please could you do some versions including the legal restrictions for various countries, for example the UK allows 25mW from 5725MHz to 5875MHz for "Wireless Video Cameras - Non Broadcasting". (https://www.ofcom.org.uk/__data/asse...70/ir-2030.pdf - IR2030/27/3 - Page #88)
Oct 19, 2019, 05:09 PM
Registered User
Quote:
Originally Posted by Bludz
BIG THANKS

Will use this when racing against some old school analogue quads tomorrow hopefully.
Hi Bludz, in your video you mentioned about the poor quality of the LQ mode. How did you switch it into LQ, as there seems to be a difference between the RunCam Racer HD manual and the ByteFrost manual.

The ByteFrost manual goes into some extra detail:
  • The camera must first be changed into LQ mode (5s press and hold right)
  • The camera must then be changed into 60FPS mode (5s press and hold down to toggle between 50FPS and 60FPS)
  • The VTX must then be power-cycled when changing between HQ and LQ modes (Presumably it only does its auto-detection at startup
  • It mentions "RX supports only 50FPS" but I'm not sure if this is referring to just the HQ mode or if the screen doesn't properly support NTSC - It might be worth testing it with the HDMI output

The reason I want to know more about the LQ quality is because the cheaper FatShark googles (E.g. Scout, Attitude V5) do not support HDMI input - But I wonder if ByteFrost could be used in LQ mode with a good quality NTSC camera and a HDMI to composite video converter as a higher quality video link that's more resilient to interference. (With a HD upgrade path when the googles are upgraded)
Oct 19, 2019, 05:42 PM
Registered User
Quote:
Originally Posted by yngndrw
Hi Bludz, in your video you mentioned about the poor quality of the LQ mode. How did you switch it into LQ, as there seems to be a difference between the RunCam Racer HD manual and the ByteFrost manual.

The ByteFrost manual goes into some extra detail:
  • The camera must first be changed into LQ mode (5s press and hold right)
  • The camera must then be changed into 60FPS mode (5s press and hold down to toggle between 50FPS and 60FPS)
  • The VTX must then be power-cycled when changing between HQ and LQ modes (Presumably it only does its auto-detection at startup
  • It mentions "RX supports only 50FPS" but I'm not sure if this is referring to just the HQ mode or if the screen doesn't properly support NTSC - It might be worth testing it with the HDMI output

The reason I want to know more about the LQ quality is because the cheaper FatShark googles (E.g. Scout, Attitude V5) do not support HDMI input - But I wonder if ByteFrost could be used in LQ mode with a good quality NTSC camera and a HDMI to composite video converter as a higher quality video link that's more resilient to interference. (With a HD upgrade path when the googles are upgraded)
I switched to LQ mode following the Fatshark manual, well actually I did it before the manual was released. Hold right, screen goes black, green light goes off on vtx. Then hold down until the vtx red led blinks. Power cycle and then as you thought, the screen can then auto detect.

I believe the 50fps lock is just for HQ mode. Now more has been said about bandwidth and I understand it better, I remember Greg saying they limited HQ to 50fps to reduce the bandwidth (or keep it under a certain bandwidth.... maybe 30hz.... memory is fuzzy). The screen does support NTSC in LQ mode, I think I saw it pop up on the screen once too. You can even notice the extra 10fps. The bitrate is so low and I think the VTX is upscaling a 480p analogue signal to 720p digital and it destroys the image. I plugged in a Runcam Eagle 2, Pheonix, Swift, Foxeer Predator V1 Mini and Predator V2 micro... all of which produced a worse image than the Racer HD in LQ mode.

If you are going to run an HDMI to composite then couldn't you just feed the HQ signal into them? Or does it display it weird? Greg said that HDO don't have an video image scaler chip because it adds 16ms latency to the goggles. I think this is only refering to hdmi input, so I'm not sure how composite works.

From peoples testing I have seen the LQ has far less penetration than HQ, contrary to on paper theory.
Oct 19, 2019, 06:54 PM
Registered User
Quote:
Originally Posted by Bludz
I switched to LQ mode following the Fatshark manual, well actually I did it before the manual was released. Hold right, screen goes black, green light goes off on vtx. Then hold down until the vtx red led blinks. Power cycle and then as you thought, the screen can then auto detect.

I believe the 50fps lock is just for HQ mode. Now more has been said about bandwidth and I understand it better, I remember Greg saying they limited HQ to 50fps to reduce the bandwidth (or keep it under a certain bandwidth.... maybe 30hz.... memory is fuzzy). The screen does support NTSC in LQ mode, I think I saw it pop up on the screen once too. You can even notice the extra 10fps. The bitrate is so low and I think the VTX is upscaling a 480p analogue signal to 720p digital and it destroys the image. I plugged in a Runcam Eagle 2, Pheonix, Swift, Foxeer Predator V1 Mini and Predator V2 micro... all of which produced a worse image than the Racer HD in LQ mode.

If you are going to run an HDMI to composite then couldn't you just feed the HQ signal into them? Or does it display it weird? Greg said that HDO don't have an video image scaler chip because it adds 16ms latency to the goggles. I think this is only referring to hdmi input, so I'm not sure how composite works.

From peoples testing I have seen the LQ has far less penetration than HQ, contrary to on paper theory.
Thank you, I don't have a setup to test but the reason I was asking about LQ with a converter is because as you mentioned, at least in theory, LQ should require less bandwidth and therefore should be much more resilient to interference. (A simplistic view that doesn't consider things like compression and overheads, but if 720p @ 50fps requires 46,080,000 pixels per second and NTSC / 480i @ 60fps / 480p @ 30fps requires 9,216,000 pixels per second, you are using 1/5th of the bandwidth and therefore at the same framerate and bandwidth usage you could send 4-5 copies of the same frame data in order to have redundancy and just pick the best pixels / blocks of data) Sadly it looks like the DM5680 IC has been build with prioritisation for HQ and so the theoretical improvements of LQ haven't been taken advantage of. (Or there could be some other technical reason of course)
Oct 19, 2019, 08:18 PM
Registered User
Daemon's Avatar
I think you're confusing date rate, and bandwidth.
If you put a lower data rate into the same high bandwidth it'll be more resistant to
interference, but if you put a lower data rate, into proportionally
lower bandwidth, you don't really gain anything at all.

Spread spectrum as we know it is all about taking a relatively low data rate (think voice,
or RC control signal or compressible data) and spreading it over *a lot* of bandwidth, then
add a PN code, packetization, retries, etc and it becomes immensely resistant to
interference. BF, being analog HD with near zero latency can't do most of those things.
Oct 20, 2019, 12:53 AM
Rotary~myPast,Present &Future!
Quote:
Originally Posted by 5zero7rc
Based on the information Fat Shark posted here about the HQ channels using 27mhz with 6mhz separation and the channel numbers from the manual, I have updated my FPV Frequency Chart to include that information. Hope it helps people understand where they might run into interference issues. I made a complete guess as to how wide the LQ bandwidth is. If no one is going to use LQ anyway, I might just remove that part.
Thank you, this is great. Was trying to figure out which frequency of the BF could be picked up by my Quanum VRX, for an RSSI-based project for the BF.
Oct 20, 2019, 03:51 AM
Registered User
Quote:
Originally Posted by 5zero7rc
Based on the information Fat Shark posted here about the HQ channels using 27mhz with 6mhz separation and the channel numbers from the manual, I have updated my FPV Frequency Chart to include that information. Hope it helps people understand where they might run into interference issues. I made a complete guess as to how wide the LQ bandwidth is. If no one is going to use LQ anyway, I might just remove that part.
Can you add all 12 HQ channels to the table please? Maybe highlight somehow that only 4 are available without permission to unlock it.
Oct 20, 2019, 09:23 AM
Rotary~myPast,Present &Future!
Some great valid points made by an old friend

https://youtu.be/RHwKwiCEKz8?t=6m
Last edited by terencechan; Oct 20, 2019 at 09:29 AM.
Oct 20, 2019, 12:45 PM
Registered User
Quote:
Originally Posted by Daemon
I think you're confusing date rate, and bandwidth.
If you put a lower data rate into the same high bandwidth it'll be more resistant to
interference, but if you put a lower data rate, into proportionally
lower bandwidth, you don't really gain anything at all.

Spread spectrum as we know it is all about taking a relatively low data rate (think voice,
or RC control signal or compressible data) and spreading it over *a lot* of bandwidth, then
add a PN code, packetization, retries, etc and it becomes immensely resistant to
interference. BF, being analog HD with near zero latency can't do most of those things.
You're right, I'm not used to the space so my terminology is wrong - but ultimately that is what I mean, to use the spare bandwidth in order to transmit duplicates of the data for the purpose of rebuilding the image in a more resilient way.

BF is not analogue, or at least it isn't internally. You can see on the DM5680 datasheet (Or the small section that they have released), the video interface is either BT.656 or BT.1120 (I suspect this is the difference between LQ and HQ).

From looking at BT.656 specs, which is based upon BT.601 - My understanding is that BT.601 defines the raw data encoding format, is not NTSC / PAL aware (I.e. It encodes the syncs as if they are normal video data) and very much handles the video stream as a traditional analogue VTX would. BT.656 seems to build upon this by encoding in an "NTSC / PAL aware" form, encoding the horizontal sync by using special start of active video and end of active video sequences. The start of active video sequence contains the line position information, meaning that artefacts such as multipath should be easier to remove (By ignoring lines which you've already received) This is really the difference between digital and analogue transmission - Where digital systems can include this additional metadata in order to aid the reconstruction of the signal.

Building upon this, there's no back-link like the DJI system to allow for re-sends of bad data but what you can do is send the frame multiple times (3-5x) one after the other. This doesn't impact the framerate as you have spare bandwidth available in LQ mode, but means that we now have multiple copies of each encoded line at the receiver. As the copies are spread out, interference is less likely to affect all of the copies of each line. The missing piece is a way to detect which version should be used for each line (Or whether or not to dim the line as I suggested in a previous message), but the solution to that is to add additional information to the end of each line which summarises the preceding data. For example if each line represented 640 pixels of data, you could sum the luminance of each 8th of the line (I.e. 80 pixels), then divide that by 80 and write that out as an extra value (Then do the same for the next 7 blocks). In effect you're sending 648 "pixels" per line, but the last 8 pixels can be used as a sort of checksum to rate the quality of that line - Then you simply pick the best line.

I don't know how much control ByteFrost has over the system in comparison to Divimath, but I simply raise how I would have expected the LQ mode to take advantage of the spare bandwidth.
Last edited by yngndrw; Oct 20, 2019 at 07:21 PM. Reason: Fixed typo
Oct 20, 2019, 07:16 PM
flying and braking frames
Quote:
Originally Posted by fatshark
Yep, you do seem to know enough to be dangerous. This system does not use differences between frames for compression thus Divimath's stated less than 1ms compression and also why it can handle lost data so well (doesn't require information from a previous frame). This system also does not use twice the bandwidth of normal analog. The reason it interferes with 2 RB analog channels is because of the way it lines up. RB channels were chosen by evenly spitting up the ham band and distributing the channels for maximum separation. Similarly the Byte Frost channels were chosen by evenly spitting up the FCC license free portion of the band. Unfortunately that means we're kinda drifting over the white line and affecting two lanes of traffic. We are considering dropping down to 3 channels and lining up directly with the RB channels.
Fat Shark
Is this the maximum compression that this silicon can achieve at 1ms?
Oct 21, 2019, 03:04 AM
Registered User
Quote:
Originally Posted by Nightstone
You stick with what you know... Fatshark is the king of analog googles. DJI is the King of HD.

3DR was the king of autopilots and took on the king of drones... that was a fiasco.

GoPro was the king of cams and took on the drone king... went really well. Not.

DJI has years of R&D into HD. DJI has a host of successful products. DJI is commercially massive.


No way can fatshark compete... Not with money or tech or R&D. This will not be a competition...

Not trolling... Just pointing out the obvious. This is a bad move for Fatshark.

NS
Wow you just know everything don't you...not
Oct 21, 2019, 03:57 AM
Registered User
fatshark's Avatar
Quote:
Originally Posted by jester9
Wow you just know everything don't you...not
His points are valid. The only piece he's missing is that the other companies expanded into other segments as an attempt to grow - and it cost them. I'm doing digital because I'm interested in the hobby and I see potential with this system. FPV is a hobby and digital is the next evolution, if I didn't have digital to work on I'd get bored and probably do something else.

Fat Shark
Oct 21, 2019, 08:18 AM
Registered User
Quote:
Originally Posted by fatshark
His points are valid. The only piece he's missing is that the other companies expanded into other segments as an attempt to grow - and it cost them. I'm doing digital because I'm interested in the hobby and I see potential with this system. FPV is a hobby and digital is the next evolution, if I didn't have digital to work on I'd get bored and probably do something else.

Fat Shark
I'm happy you are doing this! We need more innovators to keep this hobby moving forward.


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion One Mo Byte 1.9" / 2" micro build JustPlaneChris Micro Multirotor Drones 0 Mar 22, 2019 10:24 PM
Discussion Moon light twinkling off the frost... rockyboy2 Life, The Universe, and Politics 4 Jan 03, 2018 12:25 PM
Help! KK2.1.5 verification error, first mismatch at byte 0x0000 0xff != 0 avr_0xff Multirotor Drone Electronics 0 Feb 15, 2016 01:39 PM
New Product Quattro-Byte & Trilo-Byte BJADA Multirotor Drone Talk 12 Dec 15, 2011 02:52 PM