Captain Jack
Burnt out human
- Joined
- Oct 21, 2006
- Messages
- 11,808
- Reaction score
- 7,991
- Points
- 113
- My Satellite Setup
- See signature
- My Location
- North Somerset
Possibly but colour isn't technically affected on SECAM.Maybe with VBI mode bits 0-1 set to b00, the decoder is attempting a specific video processing for SECAM, that doesn't really apply to PAL (hence the red and blue PAL chroma bursts)?
You can overcome this by running it with a sample rate in multiples of 10MHz, which realistically means either 10MHz or 20MHz with HackRF (use -s 10000000 option)For example I tried D11 mode in PAL, it doesn't play nicely regarding the PAL color bursts and accentuates similar PAL chroma streaks.
As @fsphil says, it should work. The cut/rotate video I posted is in SECAM.Do you know what's currently blocking hacktv --syster to work in SECAM?
Isn't it? Full of secrets too...That nasty little black box!
The video is misleading. The source material is actually running in --syster and the box is actively decoding it. It just occasionally loses Syster lock, while also occasionally breaking into CNR.From the video you sent, I think I saw transitions from clear to lineshuffle to cut-and-rotate, but also direct transitions from clear to cut-and-rotate.
It triggers randomly relatively frequently but I have not found a way to actually force it to stay in this mode.Is it hard for you to reproduce the conditions that trigger the cut-and-rotate (CNR) decoding (like, a few seconds per hour), or is it actually quite easy to trigger? From the same video, it seems quite easy, but I may be wrong.
Well, the decoder needs a key or Goldcard to even kick in in the first place. However, I don't know whether it triggers to specific data. Unlikely, though, as it repeats the same data over and over again.Is the decoder asking the plastic key for specific data when decoder does CNR or little time before it does? i.e, is the plastic key also playing a role in decoding CNR?
Is it already reproducible with a goldcard and your .hex file ? (hope so!)
Ah yes, like Phil says, it's probably decoding half of the frame/single field rather than both. Not sure why...In my case, if vbi mode bit 3 is enabled, I have ~ 50% decoded frames: each frame is never fully decrypted, but the reordered picture still provides a much better "distinguishable" content than the original unencrypted frame.
Long story. Essentially, we are triggering some weird bug in these boxes that seem to have a 'default' permutation. Indeed, most of our keys are inactive and respond with a '0A' byte to '06 00' instruction ('give me decrypted control word' command) from decoder. This 0A byte means 'I don't have subscription to this channel' and seems to trigger the default permutation on most French and German decoders (some Polish too but not Russian).This might be unrelated but: with a goldcard, why did I have to enable#define _OPT_PIC_CARD 1
for my decoder to stably decode over time? If I don't enable this define, decoding only lasts ~0.5s.
I have two French decoders. One works as above. The other seems to respond to '0A' byte more correctly by only 'decoding' it for half a second and then losing lock (with real keys). With PIC implementation, it's actually sending a different response to the decoder rather than just '0A' - it's sending a proper 8 byte response, which fools the decoder into thinking that the card has a subscription and decodes it. However, it does it with a different set of s,r values, which is what _OPT_PIC_CARD option selects. I don't know which 8 byte word generates the 'default' set of s,r values - hence my previous question on trying to work out how s,r values are generated from these 8 bytes (50 pairs for each word).