DVB Discussion

[vk-hca]

Sam, I have the code running in Debain fine, the installed with no issue at all as per your instructions with no "debianisation" required..

For receive I converted a very cheap S band LNB used on the Indonesian SES7 signal, just bypass the filters and mixer and extend the dipoles a bit it works really well.

Also I am setting up to try and convert a cheap linux based DVB-S2 into a TCP receiver like a Novra, strangely the Chinese chip set manufacturer has produced a development board and a linux source for it. Its early days and I am still setting up toolchains and investigating the receiver and code etc,

If it becomes a reality, I would try and port Xrit into it as well.

One question is will a Novra box or DVB card process the GK-2A HRIT signal?

If you have a few minutes have a look at the LNB and receiver in my posts in these couple of forum threads..

https://www.austech.info/showthread.php/117308-Setup-for-weather-satellite-GK-2A https://www.austech.info/showthread.php/118829-An-alternative-linux-stb-with-maufacturer-support-GX6605S-and-GX6622-chipset

[sam210723]

Glad to hear xrit-rx is running well for you! The signal from the converted S-Band LNB looks great. I'm very interested to see your progress with that GX66** dev board and getting IP frames out of a set-top box. They'd be a great alternative to the Novra.

Short answer A Novra (or similar) receiver will not work with GK-2A LRIT or HRIT without modification. L/HRIT follow the CCSDS spec while the Novra front-end implements the DVB-S/S2 spec.

Long answer I've also briefly looked at modifying DVB-S/S2 receivers for non-DVB signals like GK-2A HRIT. Based on my research it would require a fair bit of modification to software (and possibly hardware) of a receiver to make this work. That's not to say it can't be done, I just decided to focus on other ongoing projects at the time.

The main issue I came across was gaining access to the raw symbol output of the demodulator before it hits the DVB FEC and frame sync logic. This would be necessary as the framing of DVB-S/S2 is completely different to CCSDS used by GK-2A LRIT and HRIT. If the symbol output was accessible the CCSDS decoding could be done in software with existing tools like goesrecv. Having a compatible CPU/MCU to run that code on is a whole other story.

Typically the DVB-S/S2 receiver ICs designed for set-top boxes will take RF in (L-band IF) and output multiplexed MPEG-TS packets (188 or 204 bytes) to the main STB processor which then demuxes them into their respective PIDs. Definitely not useful for anything using CCSDS however it looks like CMACast does use MPEG-TS. It carries data from Chinese FengYun satellites by wrapping IP frames (probably multicast UDP) into multiple PIDs of an MPEG Transport Stream. A bit strange but I'm sure it works fine. This is the reason the Novra S300D used by Kevin (Learjet) won't receive anything when tuned to CMACast.

Some more advanced receivers like the TBS6902 (or possibly a Linux-based STB) can output MPEG-TS or DVB-S2 BBFrames which are needed for something like GOES Rebroadcast (GRB) and HimawariCast as they use Generic Stream Encapsulation (GSE) or Multiprotocol Encapsulation (MPE) to wrap IP frames and make them DVB-S2 friendly. From memory some of these cards can handle GSE on-board as well. Having access to BBFrames may allow bypassing the expensive KenCast software used by HimarwaiCast.

The Novra receivers can work another layer higher than these cards by outputting complete IP frames straight onto a LAN segment after handling everything from demodulation, FEC, framing, and GSE on-board.

So, it all depends what layers you are able to access. Low down at the symbol level you could receive basically anything, but you'll be implementing a lot of custom protocol stuff in-software. Higher up at BBFrames or GSE you'll be limited to DVB-S2 compatible services like HimawariCast or GK-2A UHRIT. All the way up at MPEG-TS level it's only CMACast that I'm aware of, but that too will need custom code to unwrap whatever they've put inside those PIDs.

[vk-hca]

Thank you for the reply, especially the long answer, most informative. I am new to these formats and have a great deal to learn about them. I have been meaning to contact you but not being a FB or twitter user Github was the only option.

As for the LNB conversion, originally I left the filter between the mixer and the output amp in place but it was deaf, maybe an impedance thing, bypassing it as well as the front end filter and mixer seemed to be much better. With out any testing gear I can only assume quality by the look of it. Normally they go in a 80cm offset for S band but it seemed to be a bit small for GK-2A here. They are cheap and plentiful here online, were we have a fantastic online shopping websites but none of them are set up for overseas and paypal/ebay/amazon have zero market penetration here because it seems their expensive model can't compete. But it looks like a great cheap front end solution for any L band use.

As for the GX66** based Getmecom receivers, I was hoping it would be a one solution fits all, maybe not buy the sound of it. The more I look I see more STB boxes sold overseas using this chipset I find, the $15 gx6605s version has no ethernet and 4 meg flash, and this is the one on the dev board. The $20 receiver that arrived yesterday has the gx6622 with 8 meg flash and ethernet, its the the preferred option for this project but no apparent linux support from the manufacturer. Strange considering it has a cat5 interface on chip.

Of course there are open source code for Zgemma and VU+ receivers with more powerful chipsets to work with but its hundreds of dollars versus tens for the STB.

I think they hoped the dev board would attract the SBC community which apparently it has not. Not surprising as I have not found proper documentation on the chip as yet, pin outs, registers etc even though the they have Linux code and compiling tools with buildroot for it on C-sky github site.

Looking at the code in the receiver flash images with their setup tool I expect to find a RDA5815m rf chip and a GX1101 demod chip for which I have found some data and code, but unless the demod is under the front end can its missing meaning it might be in the main chip, but also meaning I have access to the raw IO data from the tuner. I need to wait for the gx6605s box to arrive in a couple of days and see whats in it. Testing it on C band it looks more sensitive than my other boxes.

I was hoping the front end and demod could be used by attaching esp32, Due,or equivalent controlling it like any other sensor, control with I2C and data in on an 8 bit port. But if I can use the linux support provided and use the onboard controller chip so much the better but no need of its DVB video processing and HDMI capabilities for this job.

Using the Saleae I2c option I can confirm the I2C bus operations what ever they may be.

The receiver takes a telnet login via the cat5 socket as root no pass and tells me its BusyBox v1.21.0 (2018-06-01 16:50:01 CST) multi-call binary. I have modded busy box in routers before to provide serial ports and upload AIS data in the past so that's a good start and the file system is normal.

Some looking around inside today reveals, init loads the front end and gpio as modules, likewise the network, dvb, wifi etc. /var is writable in ram, / proc is quite informative, it mounts an nfs if its then when the cat5 is connected, and an easy to boot the box on usb. No editor found but grep, sed, awk are all present also flash tools and wget.

Easy enough to get into and and run your own code, I killed their main app and I still have all the modules loaded full read write execute from the thumb stick. Better get their buildroot tool setup next. Its got some glib issue on debian so quickest option might be an ubuntu server install on a spare partition.

As the TBS boards can do the same as a Novra, I figure I can learn from their Linux sources and many other linux DVB projects how to deal with the data once I have it from the STB front end hardware.

So it looking at it now it might be possible to to grab the raw IO data in this box it could well be possible to make it do Himawari at least. There has to be a solution to the Kencast slug for hobbyists, I figure get a receiver working first deal with that next..

I have lot of documentation research, setting up, analysis work to do before I can say much about how to proceed but it looks like the road is open to figure the calls to their tuner module and see what can be done next. Putting the result to network should not be so hard.

Also it looks like I have a use for my Github page. Another long learning curve!

[sam210723]

Sounds like you've got a fair bit of tinkering to do on these STBs. I think you'll have more success with external demodulator ICs rather than the one IC doing demod + decode. The tighter integration of the GX66** ICs adds a bunch of other complexity in reverse engineering versus analysing I²C / SPI or a parallel bus right on the PCB. The fact you have CLI access already is a great start though! I'd suggest making a repo on GitHub to hold code/docs/firmware for your reverse engineering efforts.

On HimawariCast, if someone was able to give me a capture of what the S300D outputs in .pcap form I could assess the difficulty of bypassing KenCast with a custom solution. However, that's not a priority right now.

[vk-hca]

Yes a lot and most likely its not going to be easy at all, the 6605s box arrived and it is missing the demod chip also. I was working on the premise of tuner/demod/DVB in 3 stand alone chips not demod and DVB controller in one chip. The other option is a montage box but I think they are integrated now as well. There is some linux dvb code dealing with their older CS6000 chipset.

The National Chip website indicates there is a demod chip in the 3 piece 6605s chipset , but it must be in the 6605s on the same die now, which buggers things up a bit because the RA5815m tuner output is IQ diff 4 wire. However I have the data sheet with the register info for the tuner chip. Not so easy to interface to physically at operating speed and it would require the entire demod in code within an alternative processor. Short of asking them for it I cant find anything on their demod chips at all. But nothing ventured nothing gained.

I thought the gx6605s box had serial but turned out to be not the case, As yet no obvious serial in the header on the board either. So I need to get a usb wifi for it before doing anything more with it. Nice boxes, both fired up and came up with power view and biss decrypt working. Not bad for $20 delivered.

Looks like the firmware is one size fits all. Maybe OEM Customers just edit text config files for the tuner chips used, options, menus, theme graphics etc, basically its 4 kernel modules tuner, panel, gpio, dvb. It refers to the tuner in the code as GX3301 but it will be hard to figure without data sheets and I2C access. I did see some mention of bb frames in the tuner code somewhere so there is a glimmer hope.

Another nice thing is it looks for a local IP and mounts an NFS share in /home which saves a lot of mucking around. Opening the possibility of running the normal linux debug and reverse engineering tools through the buildroot tool chain and running in the receiver over NFS from the linux box. Very nice, no flashing no disk space constraints.

As its based on busy box I maybe able compile code from that project into it as well. Apart from Buildroot its got Qemu and OpenADK ? support also. The missing link is what can or can not be done with the demod but as its done in the firmware with the kernel tuner module, it should be possible to work out the calls to it and maybe its enough to get the stream. After that its just getting the stream out on tcp with busy box. I am getting the impression with the tools and support for it available the processor is not the problem, its as above, the tuner. First I need to get the tools all running on Debian, else add a ubuntu16 partition the same as c-sky use.

It was asked and confirmed ok about flashing the dev board code to a sat box. The amount of material in their repositories is quite surprising. https://github.com/c-sky

More setup, discovery and testing is required to see if the idea is even a starter. Yes, a repository of the info I have collated on git hub with test script results would be good. It would also invite collaboration and ideas from people who know more about this stuff than I do.

As for bypassing Kencast. I have had a brief look at it installed in the Debian, possibly the appropriate .so lib file could be used to just deal with the encapsulation. I thought I would have turned something on it searching in Iran or China like an MS install or a key file but so far no such luck. It would be nice to compare the same data as to what equates to crypt and its plaintext.

As for grabbing PCAP files, Learjet might be your only man, as he has the Novra and the legit Kencast running. He might not be familiar with anything like Ethereal from what he has said to me, but he did mention getting a second Novra because of some intermittent issue with the first one. Might be worth checking out for when priorities change, if not a cap drying out intermittent has a good chance of being a heat or solder problem. It those 10Eu cards do work as claimed it would be good.

However there are howtos and linux installs linked for Centos, Ubuntu 16 and Debian on this blog which I grabbed for reference later. Looks like these met kiddies don't mess with MS, but they have 80 stations using it over there, they seem to share their processing software development also. https://geonetcast.wordpress.com/2020/03/31/installing-the-gnc-a-ingestion-software-on-debian-10-3/

[vk-hca]

Just to add to that, I am pretty sure right now I could set it up to boot on the JCsat transponder freq and rate, shut down their code and have full run of the box to get at the IO data or physically pipe it off to another demod. Excepting what the agc and filter gains will do.

[kisaa]

On HimawariCast, if someone was able to give me a capture of what the S300D outputs in .pcap form I could assess the difficulty of bypassing KenCast with a custom solution.

May be, I can help you with it. I have no S300D, but PCI-e DVB-S capture card TeVii S472 (on Conexant CX23885 chip), and we use KenCast software for receiving HimawariCast data from JCSAT-2B. So, that is Himawari pcap dump from TeVii (153 MB): https://drive.google.com/file/d/1-lyt2RlUZ7LakusImJpApUoY-nP1giYN/view?usp=sharing

[vk-hca]

Thanks for that Kissa, It it turns out that these new chipset demods are capable receiving himawari stream that will be very helpful to compare with. Can you advise the time stamp on the original recorded file?

[kisaa]

File was recorded today, 06/07/2020, approx. at 01:50 GMT. It contains only one transmission session (may be, several files), as showed on the screenshot (one hour scale, bottom axis - minutes):

I'm sorry, I just discovered that there are more packets in the dump. One whole transmission (may be several files, as showed on the screenshot (one hour scale, bottom axis - minutes)) is from 0 to 429 sec, UDP multicast to 239.0.0.1

[sam210723]

Great, thanks Kisaa! Some quick observations from that capture file:

• All packets are multicast UDP to 239.0.0.1
• Image files using bzip2 compression
• Recurring uncompressed headers are present
• Normal BZh file signature for bz2 files

Uncompressed headers

bzip2 signature

I'll keep digging through the packets...

[vk-hca]

Your quick of the mark Sam, looks encouraging so far.

[sam210723]

I've successfully assembled a bzip file from the UDP stream, decompressed the HRIT file, and starting to get signs of an image. This IR1 channel is 2750x2750px just like GK-2A, so each segment is 275px tall. Looks like the HRIT files contain 10 bit raw pixel data again like GK-2A HRIT. Next step if to convert this to something sensible like 8 bit BMP or JPG.

[vk-hca]

That would that then indicate the all important big bucks PCXXXXXX.kcl file for kencast we don't have, does not include a hash block for a crypt on the signal? Its just a software enable thing.

I followed your recommendation, I started a gx6605s receiver Himawari receiver project on my github, Also is I collated a how to and pix for turning an sband lnb into an L band lna complete with a local translated version because I have seen some Indonesian guys comments on your twitter.

https://github.com/vk-hca : being origin and initials not qth and call

Kissa, are you ok with me putting your data up somewhere as sample linked to my github for future use?

[kisaa]

Kissa, are you ok with me putting your data up somewhere as sample linked to my github for future use?

Sure, you can use it or cleared version (contains only packets for one transmission, ~150 MB): https://drive.google.com/file/d/1F-cQrzRgPncSblhziscpI8Slvtx0IkO-/view?usp=sharing

[kisaa]

Some good news!

I finally got from Aliexpress a bias-tee board and connected the ETRA demodulator to a 2m dish with "cantenna" (instead of a factory-made 3m). What can I say ... of course, the signal level has become lower. But it is still enough for stable reception of the HRIT signal! The integrated ETRA monitoring reports a SNR per bit level (Eb/N0) of 5.6 dB (was 7.4) and a Viterbi error rate of about 3e-2 (was about 1e-2). But the final images are error free.

[sam210723]

@vk-hca Looks like there's no encryption applied to HimawariCast, just a bunch of KenCast framing nonsense. Shouldn't be too difficult to make sense of it all. Also nice work on the LNB mod guide.

@kisaa Good to hear! That gives us some optimism for decoding HRIT with an SDR in GNU Radio. Are you now able to take an IQ recording of HRIT on the 3m dish? The stronger signal will help with development of the demodulator.

[vk-hca]

@kissa Thanks for that, If these demods did prove to be usable for Himwarri it will be good to know what should be coming out of it.

@sam That's really good news, because when I pulled the customer list, I realised crypt was a real possibility.

Cheers on the mod, mate down there wants one so I will know what it costs to reg post one down.

I can put a 2.4 on Himawarri with an RTL-SDR and log IQ if you need, I was going to rearrange 1.8 onto it tomorrow and see how GK_2A goes on the offset. I was going to do it today but next door had the chook fights on so I did not want to make a spectacle up on the top roof with the TV etc. Also I have 3.5 but its new tracking mount is unfinished in the shed.

I assume the RTL is up to the task? Looking at the footprint I doubt its much stronger here though. But I will move it over tomorrow if requested.

BTW has you ever come across a footprint signal level chart for GK-2a?

[kisaa]

Are you now able to take an IQ recording of HRIT on the 3m dish? The stronger signal will help with development of the demodulator.

New IQ records from 3m dish (~450 MB each): https://drive.google.com/file/d/18Q2FCqR8s2am9DOI9auBJ2xESMqeAhnj/view?usp=sharing https://drive.google.com/file/d/1OBKSwnoM1_ZtfGwpWG5qhSvK0T_KJu8H/view?usp=sharing

[sam210723]

@kisaa Great, thanks for those! That's the clearest HRIT constellation I've seen yet.

@vk-hca The max 2.4 Msps sample rate of the RTL-SDR is likely going to be too narrow for HimawariCast. An Airspy Mini running at 6 Msps would be ideal. I have enough test data for the moment since I also got a TS recording from someone on Twitter.

I haven't seen an EIRP chart for GK-2A. It should be a pretty typical global beam pattern.

[vk-hca]

@sam210723 Ok on the RTL, I thought as much, and yes I could not find a GK2A EIRP chart either.

On the GX6605 receiver demod, same problem remains, I still unsure if the demod can be used and without a datasheet. Suitability for Himawari is still unknown.

But on the plus side, I have the config tool for different panels, tuners and demods, theme and internet addons etc for the core firmware, very handy for RE work for control of the panel and demod using supplied kernel modules. Tied it to the Debian box and figured out the basics.

However I have the supplied c-sky demos and buildroot tool chain up and running in Debian. I can put any linux program or code, busybox option I like into the box only from source, flash and ram space permitting using serial, usb, wifi and cat5. Easy enough to change the 8 pin spi eeprom for larger or use the thumb stick for storage.

SO it should be reasonable to assume, with the 6622 chip with serial, cat5 and 2 usb or a 6605 with 1 usb add a usb hub with cat5 network/wifi SDR and thumbstick, it should able to make a weather sat LRIT receiver from it, as they boot from usb. If there was room I could add an option to the internet menu with the tool and leave the original DVB-S2 set top functionality.

Cut to the chase, in the minimum without the demod, build SDR, goesrecv and xrit-rx combined with the supplied HDMI output demo, web server and maybe an ftp uploader. The box could boot from a stick, display the xrit-rx to the screen and output the images somehow to network. The processor is not special but maybe enough for that, I can only try it and see.

Also I have found these cheap 20$ boxes used OEM under many names, UE, RU ME US, I guess Aust will be import whatever.

Maybe the 2 rx and the demo board I brought and the last few weeks on search engines will not go to waste.