Posts by F5OEO

    Quote

    SV1BDS Hi, does your firmware support connection from GNURADIO when Tx is not operational?


    You can use like a normal SDR (and from gnuradio) when you select passthrough mode on the firmware.

    Hi George,


    Try to debugging my dvb-t modulation on pluto.

    Seems that I have a clean spectrum but never seens a constellation on the final window.

    As it is the first time I use your script, I maybe have something wrong.

    I tx BW 250Khz, QPSK/FEC 2/3,Guard 1/32


    Any suggestion ?

    73 Evariste F5OEO

    Official page list which hardware drivers are supported by Pluto. However as datv firmware is a custom kernel, I could add other drivers..just need to know which to add ! Some extra wifi like TP_LINK are already added.

    Laurent, I could help you by teamviewer because your issue is not trivial , write me a mail?

    Excellent news Roberto. Seems to work !

    About embeded encoder : I have a proof of concept using a 10 Euros usb dongle HDMI input . I can encode mpeg-2 at SD (720x576) abd even H264 SD (with worst encoding quality). It could be helpfull to portable as no PC is required.

    About x265, I could add it , but doubt that PLuto could do more than CIF (352x288)...I could add it if any interest.


    About udp and tcp port...Yes we can add parameter for that (but need to add it on web interface and fw_setenv). Furthermore, right now, udp and rtmp are running in pararalel. We could optimize that with an other parameter which set the mode we wan,t to run.


    73

    EVariste

    Thanks for these details...I just break my toolchain , so remake all. My firmware is now wierd : it's booting and after few seconds start blinking. It seeems that you have a hardware serial to see kernel message. If so you could maybe help me debugging it ?


    For your issue, that is my fault : patch is done on S89..all scripts before (S21 for example) is not updatable.

    Further more jffs2 is done on S23udc so nothing could be read/write before that.

    An alpha version is available at http://firmware.hackhamradio.com/alpha/

    As I rebuild completely the toolchain, some regression could appear. This is only for development testing and to help contributors to patch.

    It is based on v0.32 original AD firmware.


    To apply a patch, make a zip : all files will be extracted at / of pluto. Patch is done at every reboot. (see zip attached for example)

    The easiest method to apply patch is by using web interface.


    Thanks for feedbacks.


    73 Evariste F5OEO

    Files

    • patch.zip

      (317.96 kB, downloaded 222 times, last: )

    Thanks in contributing to the project with your patches. Right now, the only easy method is by using an USB dongle. The next firmware will be based on official 0.32 firmware which have 1M of permanent memory.

    This partition is shared by network (NFS and maybe Samba for windows users) and if you put a "patch.zip", it extracts it and patch the firmware...so everyone could easily modify the datv firmware for testing.


    73 EVariste F5OEO

    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...


    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