Hello!
I am a hobbyist from France.
My goal is to make some experiments on DATV. I would like to build a "DVB multiplexer" for a DATV repeater. This multiplexer could mix several programs received, and send them to several TS, for several down-links. 1 link for "broadcast", and the other link would be microwave to another repeater. All this could be made without a PC, just with microcontrollers. The main difficulty on this project is to find a DVB FEC encoder. All the other components are available at a reasonable price. That is why I am interested on the Digilite project.
I have some questions about the digilite project:
1) The data link between FTDI and dsPIC : what does this link transport? Is it directly a "transport stream"? Therefore, could I put a FIFO instead of the FTDI, and send a TS to this FIFO? This transport stream would be send by my home-made DVB multiplexer.
If it is not a pure "transport stream" between FTDI and dsPIC, could you please give us a description of the differences between a TS and this?
2) dsPIC control protocol: Could you please give us a description of the protocol that gives instructions from the PC to the dsPIC? I think that this protocol would be easily reproduced by a microcontroller (my multiplexer) instead of a PC.
3) push to talk : Do you plan to build a "push to talk" on this board? It would be a good Idea, for "duplex" links, or for shared uplinks, like a repeater. The next Idea is to build duplex links between repeaters, and with a kind of simple TDMA protocol.
4) Is this Digilite project open source? I understand that it is not currently "open source". But it will probably be open source in the future. Am I correct?
5) FEC encoding on microcontroller : Is it a great effort to port the FEC encoding on a 32 bit microcontroller? I am a little bit used programming on ARM 32 bits microcontrollers. Where did you find a detailled description of the FEC algorithms? Could you please share your source of information?
Thanks a lot for all your answers.
Regards,
Leon.
Questions about adapting Digilite for non-PC use
Re: Questions about adapting Digilite for non-PC use
Hi Leon.
1. The data between the PC and serialiser is just a stream of bytes. The serialiser does not care what it is. There is no packetisation or software flow control. There is a FIFO of 13.5kB in the serialiser. More would be better.
2. The Control port is set to 57600,N,8,1,noflow. The PC configures the serialiser with commands such as A:SRF4000,3<CR> to set the symbol rate to 4000 and the FEC to 3/4. Only certain symbol rates are possible. The serialiser sends status messages to the PC, the most important one being to tell the PC that there was a break in the data stream.
3. What would a 'push to talk' do? Stop the data or drop carrier?
4. The project may become open source at some point, but it will need a lot of cleaning up first.
5. It's difficult to find all the info in the same place.
http://1-core.com/library/comm/viterbi/
Figure 1 shows the shift register configuration that produces the Viterbi 1/2 output.
http://www.etsi.org/deliver/etsi_en/300 ... 10102p.pdf
Table 2 shows the puncturing masks to derive the other FEC outputs from the base 1/2 output.
Brian
1. The data between the PC and serialiser is just a stream of bytes. The serialiser does not care what it is. There is no packetisation or software flow control. There is a FIFO of 13.5kB in the serialiser. More would be better.
2. The Control port is set to 57600,N,8,1,noflow. The PC configures the serialiser with commands such as A:SRF4000,3<CR> to set the symbol rate to 4000 and the FEC to 3/4. Only certain symbol rates are possible. The serialiser sends status messages to the PC, the most important one being to tell the PC that there was a break in the data stream.
3. What would a 'push to talk' do? Stop the data or drop carrier?
4. The project may become open source at some point, but it will need a lot of cleaning up first.
5. It's difficult to find all the info in the same place.
http://1-core.com/library/comm/viterbi/
Figure 1 shows the shift register configuration that produces the Viterbi 1/2 output.
http://www.etsi.org/deliver/etsi_en/300 ... 10102p.pdf
Table 2 shows the puncturing masks to derive the other FEC outputs from the base 1/2 output.
Brian
Re: Questions about adapting Digilite for non-PC use
Thank you for your fast answering.
Leon.
OK, but if I select "FEC on serializer", and if I send a " raw MPEG Transport Stream" from the PC to the serializer, is it OK? Does it make a DVB-S signal at the output of the Digilite board? Or the format for the incomming data stream is different, in order to make a DVB-S signal?G4EWJ wrote:1. The data between the PC and serialiser is just a stream of bytes. The serialiser does not care what it is. There is no packetisation or software flow control. There is a FIFO of 13.5kB in the serialiser. More would be better.
Both are necessary : stop serializing the data, and stop the RF signal at the output.3. What would a 'push to talk' do? Stop the data or drop carrier?
Leon.
Re: Questions about adapting Digilite for non-PC use
It depends on the exact definition of the various streams.
If you select 'FEC on PC' the serialiser simply sends the even bits to I and the odd bits to Q. It assumes (but doesn't know or care) that all the DVB steps have been applied to the 188 byte transport stream packets: sync inversion, energy dispersal, Reed-Solomon, interleaving, Viterbi (FEC). The PC sends A:SRF4000,0 on the control port to the serialiser to tell it not to do any FEC processing. For 'historical' reasons, in this mode the serialiser expects the bit order in the bytes to be reversed from normal.
If you select 'FEC on serialiser', the serialiser expects that all the DVB steps apart from Viterbi have already been applied to the 188 byte transport stream packets. It applies the FEC according to the A:SRF4000,x command it received from the PC.
You can stop the serialiser sending by putting it into a test mode, but there's no provision to turn off the rf output.
Brian
If you select 'FEC on PC' the serialiser simply sends the even bits to I and the odd bits to Q. It assumes (but doesn't know or care) that all the DVB steps have been applied to the 188 byte transport stream packets: sync inversion, energy dispersal, Reed-Solomon, interleaving, Viterbi (FEC). The PC sends A:SRF4000,0 on the control port to the serialiser to tell it not to do any FEC processing. For 'historical' reasons, in this mode the serialiser expects the bit order in the bytes to be reversed from normal.
If you select 'FEC on serialiser', the serialiser expects that all the DVB steps apart from Viterbi have already been applied to the 188 byte transport stream packets. It applies the FEC according to the A:SRF4000,x command it received from the PC.
You can stop the serialiser sending by putting it into a test mode, but there's no provision to turn off the rf output.
Brian
Re: Questions about adapting Digilite for non-PC use
I understand that in "FEC on serialiser" mode,G4EWJ wrote:If you select 'FEC on serialiser', the serialiser expects that all the DVB steps apart from Viterbi have already been applied to the 188 byte transport stream packets.
* the PC makes the "randomization", Reed-Solomon coding and interleaving
* the dsPIC makes the "convoltional coding", and I-Q signals generation.
Is my understanding correct?
OK, no problem. I can adapt the board by myself, so that I can stop the output RF signal. If I use the Digilite concept, I will make a custom PCB.You can stop the serialiser sending by putting it into a test mode, but there's no provision to turn off the rf output.
What is the serial instruction for the dsPIC to enter/leave the "test mode"?
Thank you for your answers. This is very usefull for understanding the Digilite project. I will keep you informed about my projects.
Leon.
Re: Questions about adapting Digilite for non-PC use
That's correct.I understand that in "FEC on serialiser" mode,
* the PC makes the "randomization", Reed-Solomon coding and interleaving
* the dsPIC makes the "convoltional coding", and I-Q signals generation.
Is my understanding correct?
The test modes are activated by using negative values for the FEC. A:SRF4000,-1 selects 'No Mod' where the I and Q outputs are static. The LED blinks in groups of 6 when a test mode is active. Use a positive value for the FEC to return to normal transmission mode.
Brian