Receivers appear to vary in their ability to receive a transmission if the PIDs are different from those of the transmission that was used to scan and store the channel for the first time. My Fortec Star 4000 blinks its 'No Signal' icon on and off when receiving different PIDs.
Some receivers don't appear to care and presumably make the decision that if there is only one program in the stream then it makes sense to decode it. The PMT (program map table) contains all the PIDs used by any program, so they are easily available to the receiver.
As DATV becomes more popular, it would be good to try and formulate some sort of standard to prevent or reduce problems. What are the PID setting capabilities of the various systems in use? Are some some fixed? Systems I can think of are AGAF, SR Systems, NDS, PMDATV, DigiLite. Can anyone with these and other systems let us know.
The 5 main PIDs are PAT, PMT, VIDEO, AUDIO and PCR. At the moment, DigiLite uses the same PID for VIDEO and PCR but can set the other PIDs to any other unique valid number (32-8190). This is fairly common. The next release will allow a different PCR PID. I believe that NDS systems must have unique PIDs.
The main job of the PCR PID is to phase lock the 27MHz oscillator in the receiver to the reference oscillator in the transmitter. On those receivers that apparently adapt to any PIDs, I don't know if they would adapt to the different PCR PID or whether the receiver may eventually lose lock.
Brian
Defining a set of 'standard' PIDs.
Forum rules
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
This forum is run by the BATC (British Amateur Television Club), it is service made freely available to all interested parties, please do not abuse this privilege.
Thank you
Re: Defining a set of 'standard' PIDs.
There is also a discussion on PIDs under way on the Yahoo DigitalATV group
Dick G4BBH
Dick G4BBH
Re: Defining a set of 'standard' PIDs.
That's what prompted me. 
Brian
Brian
Re: Defining a set of 'standard' PIDs.
Hi Brian,
this topic was raised at the last RSGB ETCC meeting, including standards for SR and FEC. The concern is that the switch to digital is now beyond the initial "investigation/feasibility" stage and the lack of standards will impede interoperability for users with access to more than one Digital ATV repeater; something that becomes a real limiting factor under enhanced conditions.
We hope to have some points for further discussion at the next ETCC meeting.
It will be interesting to see how the international community treat the issue on the Yahoo list.
73 de Darren
G7LWT
this topic was raised at the last RSGB ETCC meeting, including standards for SR and FEC. The concern is that the switch to digital is now beyond the initial "investigation/feasibility" stage and the lack of standards will impede interoperability for users with access to more than one Digital ATV repeater; something that becomes a real limiting factor under enhanced conditions.
We hope to have some points for further discussion at the next ETCC meeting.
It will be interesting to see how the international community treat the issue on the Yahoo list.
73 de Darren
G7LWT
Re: Defining a set of 'standard' PIDs.
about FEC:
the second generation of DVB demodulator chips detect automatically the Fec. The chip works always in auto Fec detect, so you cannot set the Fec, you can only set which fec you let the chip find in a list, the chip working in auto Fec detect mode ( the only mode that it can work) will search the Fec in the list you have set.
I have even seen different hardware+firmware where, when you give a false Fec, takes the good one, ignoring your Fec.
so no need to give the Fec.
about the PID:
Problem come with software that are in SteTopBoxes that are thought for Broadcast stations that don't change often the PID for a frequency and SR.
When a receiver is lock on a Freq+SR, it can find all the PIDs. So I think that we never will have "standard" PIDs. For many reason they are not always the same in my transmission (TS files pre recorded, TS from one kind of muxer, TS from other sources I receive and remux in rel time...)and I don't care and it's not a problem for all people that use a PC+ software to receive DVB.
I think the solution is more to find/develop a good software/firmware that to restrict the possibilities of use, or to struggle for fixed values that will be very difficult to impose.
And for me, with my way of working, it is impossible to use always the same PIDs.
even for DATV relay, they don't have to know the PIds if they just re transmit the TS received, and if they must demux and remux, finding PID could be done easily.
Giving fixed PIDs values would be only a temporary solution but cannot be the solution for the future.
So for the moment I only have to give my SR to be decoded. ( second generation Demodulator chips can do a SR search, but it takes time)
about SR:
the third generation of DVB demodulator chips like STV0903 can find quickly and automatically the SR ("blindscan" function)
So in the future, we just have to look if there is a signal on the frequency, no need to know the Fec, to know the PIDs, to know the SR.
But yes that is the future, but it is not very far and will give us more facilities for our hobby.
Jean Pierre
( I understand that today, many OM use SetTopbox, and that it is not always easy to go in different menu to set PIds or scan new PIds...)
the second generation of DVB demodulator chips detect automatically the Fec. The chip works always in auto Fec detect, so you cannot set the Fec, you can only set which fec you let the chip find in a list, the chip working in auto Fec detect mode ( the only mode that it can work) will search the Fec in the list you have set.
I have even seen different hardware+firmware where, when you give a false Fec, takes the good one, ignoring your Fec.
so no need to give the Fec.
about the PID:
Problem come with software that are in SteTopBoxes that are thought for Broadcast stations that don't change often the PID for a frequency and SR.
When a receiver is lock on a Freq+SR, it can find all the PIDs. So I think that we never will have "standard" PIDs. For many reason they are not always the same in my transmission (TS files pre recorded, TS from one kind of muxer, TS from other sources I receive and remux in rel time...)and I don't care and it's not a problem for all people that use a PC+ software to receive DVB.
I think the solution is more to find/develop a good software/firmware that to restrict the possibilities of use, or to struggle for fixed values that will be very difficult to impose.
And for me, with my way of working, it is impossible to use always the same PIDs.
even for DATV relay, they don't have to know the PIds if they just re transmit the TS received, and if they must demux and remux, finding PID could be done easily.
Giving fixed PIDs values would be only a temporary solution but cannot be the solution for the future.
So for the moment I only have to give my SR to be decoded. ( second generation Demodulator chips can do a SR search, but it takes time)
about SR:
the third generation of DVB demodulator chips like STV0903 can find quickly and automatically the SR ("blindscan" function)
So in the future, we just have to look if there is a signal on the frequency, no need to know the Fec, to know the PIDs, to know the SR.
But yes that is the future, but it is not very far and will give us more facilities for our hobby.
Jean Pierre
( I understand that today, many OM use SetTopbox, and that it is not always easy to go in different menu to set PIds or scan new PIds...)