On Sun, Jul 17, 2005 at 10:49:57PM +0200, Johannes Stezenbach wrote: > On Sun, Jul 17, 2005 Andreas Oberritter wrote: > > On Sun, 2005-07-17 at 16:03 +0200, Peter Hettkamp wrote: > > > - The best solution might be to only store the requested burst command on a > > > call to send_burst, and include the correct burst bit in the start_diseqc > > > sequence in send_msg. This would, however, require applications that want to > > > send bursts do do so before calling send_msg, > > That's not good, because the DiSEqC spec requires the burst to be > sent after the DiSEqC message, so usually apps do it that way > (in VDR one can configure it, though). Ok, then it has to be done the other way round... store the message from send_msg, then send both the (stored) message ant the burst on the call to send_burst. Will send_burst be called by every application? With the cx24110, hardware can handle both the sending of DiSEqC 1.1 and the tone burst. The voltage and continuous tone can be set at any time. When the DiSEqC handling circuitry is started, it does all of these things: 1.) The continuous tone is stopped (if present) and the voltage is switched if necessary (*) 2.) After 15ms of silence, the DiSEqC message is sent (unless suppressed by setting bit 2 of 0x77...). Possibly, more than one message or messages longer than 6 bytes can be sent (will need additional code though). 3.) After another 15ms of silence, a 12.5ms tone burst, either modulated or unmodulated, then again 15 ms of silence, then the continuous tone is switched on again. This basically means that when this sequence is triggered, ALL the information needs to be present. So, WHEN do I start the output of the DiSEqC sequence? On a call to send_msg, to send_burst, both, or on some other ioctl? > > > > and also require them to call > > > send_msg even if they have no message to send (which may break again since > > > the hardware always sends at least 3 bytes of diseqc message unless the > > > message is suppressed completely via bit 2 of 0x77.) > > That's not good, either. I agree. > > > > LNBDC and ContinuousTone are easier in this respect, just set the correct > > > bits in 0x76, and all is well, i.e. according to my reseach they seem to take > > > immediate effect with or without a start_diseqc sequence. According to (*) above, I might be wrong at this... It has been a while since I ttested this, anyway > > > > > > - If anybody has a better solution for this, feel free to mail me about > > > this. If anyone feels the need to donate DiSEqC equipment with known > > > behaviour (does it switch both on Mini-DiSEqC and DiSEqC commands, or, > > > better, on only one of them), contact me, we can work something out ;) > > > > if you can set the continuous tone, then you can probably use it to do > > DiSEqC and tone burst in software. The skystar driver does it. See > > flexcop-fe-tuner.c. I might, but probably I am much too lazy to do this, seeing that the hardware can already do this... > > That sounds a bit ugly. I cleaner solution would be to > go a few years back and add something like SEC_SEND_SEQUENCE from > http://linuxtv.org/cgi-bin/viewcvs.cgi/DVB/ost/include/ost/Attic/sec.h?rev=1.3&hideattic=0&view=auto I would hate to change the existing API (there probably WAS a good reason to discard SEC_SEND_SEQUENCE in favor of the separate ioctls, wasn't it?), but I am somewhat at a loss how to do it correctly with the current API. If the lines are left in, the line in send_msg will have to be changed to &~0x04 in any case. IF applications always call send_msg first and send_burst second, or not at all, AND messages are always less than 7 bytes long, removing both sets of lines will actually bring on a correct result: - on the call to send_msg all registers except the type of burst to be sent will be set up correctly and should be left behind in a correct state for re-sending the same message again. - on the call to send_burst, the burst bit will be set to the correct value and the whole sequence will be repeated. As Adam's experience shows, this seems to output the complete message again - if DiSEqC messages of seven or more bytes need to be sent, the current code cannot handle it anyways. Therefore, if nobody objects to it, please remove the lines (or enclose them with #if 0) and we shall see what happens next. Best regards, Peter -- "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" (Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20050719/83dab79e/attachment.pgp
