QO-100 Beacon, bad TS

1st Official Post

    Hello,


    When I started this morning (6h32 local) the beacon TS was very bad with constant PCR errors (here 8592 errors after 1 mn)


    Octagon SF8008 is not a professional DVB receiver, so we know that this kind of basic receiver can accept errors without showing a problem, because they don't take care of timing, do not try to sync video and audio etc.... This kind of receiver just play the video data and audio data when they come, and don't take care of Ttime stamp.

    (This is the way the HamTV station on ISS was tested before launch and in result HamTV TS produced was very bad with no DVB tables....)

    Sorry, but my opinion is that we should never use that kind of receiver to test a DVB signal, it is a waste of time and I have never seen a professional operator doing that. It does exist professional receiver for that.


    So all the professional analyzer I use says that PCR is too much ( here 639 µs instead of less than 500 nS)


    So I can say that at 6h32 the Beacon signal was horrible about timing, with constant PCR errors. Is is impossible to get a fluid video and audio if we use a professional receiver that take care of PCR PTS or with the Microsoft demultiplexer that take care of PCR PTS.

    Yes, if I use a basic receiver, I could see a fluid video, but that doesn't indicate that the TS is DVB compliant regarding TR101 290.


    Perhaps your Experts have looked at the PCR PTS at another time in the day, but if they have tested it this morning, they see this very bad result.


    73 Jean-Pierre F6DZP


    • Official Post

    Hi Mike,


    Yes, we are not denying anything.. we are just trying to better understand the different observations and facts.


    The "reboots" needed before the change on the DATV beacon have been tracked back and had to do with a bug in the Firmware which was fixed together with the DATV beacon change some weeks ago..


    I just want enough technical evidence before grabbing the "red telephone" to call the satellite control center to make a reboot of the DATV equipment.


    So let's wait for more analysis from our DATV team..


    73s Peter

    Peter,


    I have written:

    Quote from F6DZP

    Perhaps your Experts have looked at the PCR PTS at another time in the day, but if they have tested it this morning, they see this very bad result.

    same suggestion than Mike.

    I don't want to discredit anyone, I just want to understand why I have measured this bad values this morning.

    I just want to understand, why we can receive many other stations without problem, why we could receive the Beacon at SR2000 during several months without any problem, and now, very often, we have difficulties to receive it without problem.


    About the use of Octagon SF8008, I though I have well explained why we cannot use it for testing.


    I can send you the TS I have recorded this morning, If your Experts need/want to examine it.

    and if their measurement is good , I will be glad to discuss with them about this difference and understand why I am wrong.



    73

    Jean-Pierre F6DZP

    Hello,


    I continue to investigate.


    Problem summary:

    - Since we have a new Beacon_TS at SR1500, sometimes, not always, we can get a jerky video when we use Minitioune+MiniTiouner.

    (yesterday morning it was very jerky on my station, this morning video is not jerky...)

    - This problem was never seen when the Beacon-TS was et SR2000.

    - The jerky video depends also of the codec we are using under Windows, I have tested different of them, but when it is better, I don't really know if it is the change of codec or the change of the moment I do next observation after changing the codec..

    - We don't have this jerky video when we receive a DATV station on QO-100 (supposing the TS transmitted is well encoded)



    I take the two statements A and B as the truth:


    A) I suppose that, as Peter and Experts say, the "PCR accuracy" (not the "PCR jitter" ) is correct at the origin (+/- 200 ns) in the TS produced.


    B) I suppose that, as StreamXpert Analyzer says "PCR accuracy is very bad (about +/- 780 µs) when I receive the TS via UDP from Minitioune.


    Remark:

    This Beacon_TS is also a bit "special" compared to our habits : the PCR data used a separate PID. Most of time PCR data uses the same PID than the video data( in our DATV transmission) . Perhaps it is one (allowed) specification that causes the problem?


    analyzing the relation PCR/PST audio and PCR/PTS video seems always good this morning. EDIT : NO!!! NOT GOOD AT ALL,see later post

    but analyzing PCR accuracy gives bad result


    Can the way Minitioune receiving a TS with PCR using a PID different from videoPID could causes the problem?

    Can the computer clock, the Minitioune Clock, anything else influence the result?


    As I say, I continue to investigate...


    73s

    Jean-Pierre F6DZP

    I have a little TS from the Beacon at SR2000.

    I look at it...

    PCR accuracy is also not very good, but ... but PCR/PTS timing is good (positive)


    OOHHH!

    Yes, I think I have the reason why we have problem with:


    Analyzing the TS from Beacon SR1500:

    not only PCR accuracy is very bad but .... PCR/PTS timing is NEGATIVE!!

    that means that the software ask do display video at a time relatively negative (= playback).

    So the demultiplexer/decoder do what it can to try to make up for the backlog.

    Perhaps this PCR/PTS value change over time and we get less jerky video.


    here are the PCR/PTS_video values for a good TS made by a Minimod at SR2000, the values are about +700ms, so we ask the decoder to render the video 700 ms before the PCR clock corresponding arrives, to let the time to the buffering proccess , decoding process to do their job




    Here is the Beacon at SR2000 we had in March: again the PCR/PTS is positive, we let about 450 ms to the decoder to do the job


    Here is the PCR/PTS timing we have with the new Beacon at SR1500: The PCR/PTS value is NEGATIVE!!!


    So a demultiplexer/decoder process can't go back in time, so do what it can...


    and not only the PCR/PTS is negative but the PCR accuracy is also always very very bad.



    Jean-Pierre F6DZP


    Just to confirm same analysis here :

    Stream is not ETR290 compliant. PCR accuracy is +/- 800us instead of +/-500ns. It is not very smart but should not be too disturbing.

    Profession Dectek StreamXpert is used to do that, which is equivalent to your R&S for this kind of measure.


    The main issue, is effectively the -500 ms of PCR/PTS (It is not measured by ETR290). This means that decoder is asked to display a picture which is not yet arrived (500ms late). Strategy of decoders to handle this issue depending on the decoder.


    VLC for example, try to increase the input buffer in order to display later pictures :

    "

    main warning: picture is too late to be displayed (missing 281 ms)

    main warning: picture is too late to be displayed (missing 259 ms)

    main warning: picture is too late to be displayed (missing 250 ms)

    main warning: picture is too late to be displayed (missing 230 ms)

    main warning: picture is too late to be displayed (missing 210 ms)

    main warning: picture is too late to be displayed (missing 190 ms)

    "


    SF8008 could have also this strategy..but it is a workaround. As clock is not precise, we could then have some issue between audio/video synchronisation.


    Professional decoders (Tandberg, Scopus ...) doesn't allow for such errors and do not display a picture at all.


    This issue has already been seen regularly with 2MS beacon, and was recovered by a reset of the encoder/modulator.

    It seems that at 1.5MS the issue could happen more regularly.


    Right now, it seems that the beacon is performed by Raspberry looping a video and output it to HDMI whish is then H264 encoded and modulated by SR System. The system could drift over time and could explain such errors (long term stability is not so easy in DVB).


    We hope that we could make analysis just after a reset to confirm this analysis.


    As Mike said, we are a community which include experts (DVB for example). Goal is to experiment and improve system..thus, could interesting to discuss and exchange with "The" team to share knowledge when we have such issue.


    73 Evariste F5OEO

    This is interesting. Evariste says the beacon is encoded in real time. Given it does not change I had always assumed that the audio and video were pre- encoded with the highest quality settings, multi-pass, in non-real time, latency not a problem, on some professional equipment and then saved for transmission. That's why the content never changes I thought. If it's re-encoded each pass then it could have things added to it, like a clock, TLEs or alerts.


    Mike

    Yes Mike, the most efficient way would be to offline encode the video (double pass encoding) and replay it with PCR/PTS correction (for continuous time over loop). For that , it needs an input TS file on the modulator side which is not the case on the current system as it is design for HDMI live encoding purpose. This is a choice of the team...

    • Official Post

    The DATV beacon stopped working around 05:30 UTC this morning.

    On our request a successful restart of our DATV Beacon hardware was performed earlier today.

    Otherwise no changes.


    Thomas DG5NGI analyzed earlier TS-stream recordings and meanwhile confirmed the observations.

    He is currently investigating the problem.

    Hello,


    Most of time the beacon TS is very bad. As I have said in April,( new version Minitioune V0.9.9.1 )


    Analyzing the TS from Beacon SR1500:

    not only PCR accuracy is very bad but .... PCR/PTS timing is NEGATIVE!!

    that means that the software ask do display video at a time relatively negative (= playback).

    So the demultiplexer/decoder do what it can to try to make up for the backlog.

    This PCR/PTS values change over time and we get more and more jerky video


    When you reset it, it is good only a few days, but every day the PCR/PTS timing loose some ms and so, after n days, is negative.


    It is really annoying that the QO-100 beacon, a reference for all people that begin to work with QO-100, is so bad.

    Minitioune, that uses the Microsoft demultiplexer is very sensitive to very bad TS like that, so gives only jerky video.

    Professional receiver cannot receive also TS with bad timing.


    After 4 months, no solution for that?


    Jean-Pierre F6DZP

    • Official Post

    We understand your impatience and be assured that we are not satisfied with the current situation either.


    Unfortunately, we could not foresee that the reduction of the symbol rate and lower bandwidth of the DATV beacon, demanded by many users, would lead to such problems.


    4 months ago nobody could have foreseen the effects of COVID-19.

    We have people in our team who are affected by this both professionally and privately! Since all people involved in the project volunteer their working time to AMSAT-DL, this does not remain without effects.


    The described problems of the DATV beacon are well known, but there is no short-term solution either, as all planned trips to Qatar have been cancelled for this year due to Corona.


    Our HW/SW developers have localized the problem in an encoder chip. This is a bug that appears especially with the current parameters and lower symbol rates. Attempts to fix this by a workaround in the software unfortunately did not lead to the desired success.


    Therefore we plan to replace the DATV transmitter in Qatar with new hardware. Due to Corona this will be possible next year at the earliest.


    Last month we had already planned a Firmware update, which uses a watchdog to restart the hardware every 24 hours. This should then eliminate or reduce the accumulating timing errors.


    The remote access to our hardware in the control center at Es'hailSat requires some arrangements and coordination. We hope that the new firmware can be loaded as soon as possible.


    73s Peter DB2OS, AMSAT-DL QO-100 Team

  • DB2OS

    Changed the title of the thread from “QO-100 Beacon has a very bad TS” to “QO-100 Beacon, bad TS”.

    Hello Peter,


    Thank you for the information.

    I apologize if I disturb you, but I receive very often mails from people that just start to receive QO100 and after installing Minitioune, send me a mail asking why the beacon video is jerky and spend many time to install different codec, uninstall , re install again and spend many time to try to solve a problem that is not from their installation. So I must explain each time that the beacon TS has a problem.

    Yes I understand that, with Corona, it is not easy.

    The beacon video is a reference and all of us hope that the problem with the TS timing will be fixed ASAP.

    Thanks for the effort made by the whole team.


    73s

    Jean-Pierre F6DZP

    • Official Post

    Today the DATV beacon stopped completely.


    After a hardware reset was performed the DATV beacon was back with nominal level, but with garbage TS.


    A second reset procedure also did not cure the problem.



    For tomorrow at 08:00 UTC we have planned a remote maintenance session for further analysis by our DATV-Team, including Firmware update.


    And please remember, the A71A DATV Beacon frequency is *exclusively* reserved for our groundstations and should not be used even if the Beacon is Off; Thank you!

    • Official Post

    This morning the DATV-Team (Thomas&Stefan) successfully performed remote-update of the Firmware and the DATV Beacon is back to normal.


    As an additional countermeasure a SW watchdog will perform a reboot every 24 hours. During the reboot the DATV Beacon will stop for a short period.