Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build issue. I'm assuming your
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build
Heino Goldenstein wrote:
Hello Klaus,
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the
Hello Klaus,
Klaus Schmidinger wrote:
Heino Goldenstein wrote:
---8-8-8-8-8-8-8-8-8-8---
FWIW:
I reviewed your e-mails to understand your SAT-hardwaresetup. From your
descriptions I guess you have something like this:
some ASCII art:
Heino Goldenstein wrote:
Hello Klaus,
Klaus Schmidinger wrote:
Heino Goldenstein wrote:
---8-8-8-8-8-8-8-8-8-8---
FWIW:
I reviewed your e-mails to understand your SAT-hardwaresetup. From your
descriptions I guess you have something like
From: Heino Goldenstein [EMAIL PROTECTED]
I reviewed your e-mails to understand your SAT-hardwaresetup. From your
descriptions I guess you have something like this:
some ASCII art:---
|Switch 1 |
|E0 10 38
Hello Klaus,
Klaus Schmidinger wrote:
---8-8-8-8-8-8-8-8-8-8---
S19.2E 11700 V 9750 v [E0 10 38 F0] W100 [E0 10 38 F0]
S19.2E 9 V 10600 v [E0 10 38 F0] W100 [E0 10 38 F1]
S19.2E 11700 H 9750 v [E0 10 38 F0] W100 [E0 10 38 F2]
S19.2E 9
Robert Schlabbach wrote:
From: Heino Goldenstein [EMAIL PROTECTED]
S19.2E 11700 V 9750 v [E0 10 38 F0] W100 [E0 10 38 F0]
S19.2E 9 V 10600 v [E0 10 38 F0] W100 [E0 10 38 F1]
Sorry, but - wouldn't the second part of this line reconfigure the Relay?
I'd say this command switches
Heino Goldenstein wrote:
S19.2E 11700 V 9750 v A W100 [E0 10 38 F0]
This still violates the spec. Burst must come after DiSEqC message:
S19.2E 11700 V 9750 v W15 [E0 10 38 F0] W15 A W15
Johannes
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe linux-dvb as
Johannes Stezenbach wrote:
Andrew de Quincey wrote:
its not the firmware.
its not the frontend driver (that was a different issue).
well, pretty obvious where it has to be really; must be a card setup problem
in the OSS code. I'll have a closer check over the next few days.
Like I
the actual DiSEqC signal is generated fom inside the firmware.
But since the firmware hasn't changed between the latest DVB driver
and dvb-kernel (at least as far as i know) I would assume that
the actual signal the firmware generates should still be the same.
Unless, of course, some other
Andrew de Quincey wrote:
the actual DiSEqC signal is generated fom inside the firmware.
But since the firmware hasn't changed between the latest DVB driver
and dvb-kernel (at least as far as i know) I would assume that
the actual signal the firmware generates should still be the same.
This change was done to avoid glitches in recordings on the primary device
in case the channel is switched.
Does it change anyting (DiSEqC wise) if you comment that line out?
No idea, sorry, I only have budget cards; I'm just suggesting things.
--
Info:
To unsubscribe send a mail to [EMAIL
Andrew de Quincey wrote:
This change was done to avoid glitches in recordings on the primary device
in case the channel is switched.
Does it change anyting (DiSEqC wise) if you comment that line out?
No idea, sorry, I only have budget cards; I'm just suggesting things.
I tried it now,
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the same
version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file, dvb-ttpci-01.fw
However the file format of dvb-ttpci-01.fw is obvious:
4 byte magic
4 byte number
On Saturday 20 March 2004 15:26, Andrew de Quincey wrote:
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the
same version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file, dvb-ttpci-01.fw
Actually maybe I have a
Andrew de Quincey wrote:
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the same
version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file, dvb-ttpci-01.fw
However the file format of dvb-ttpci-01.fw is obvious:
Andrew de Quincey wrote:
On Saturday 20 March 2004 15:26, Andrew de Quincey wrote:
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the
same version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file,
On Sat, 20 Mar 2004 16:35:37 +0100
Klaus Schmidinger [EMAIL PROTECTED] wrote:
I believe the file http://linuxtv.org/download/dvb/dvb-ttpci-01.fw.gz now
contains the latest firmware version (the previous file was not gzipped).
Klaus
FYI there's a tool in the scripts folder of the
On Saturday 20 March 2004 15:34, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
Incidentally, even though the firmwares used by 1.0.0 and 1.1.0 have the
same version number, they are _not_ the same.
1.0.0 had two seperate files, Dpram and Root
1.1.0 has a combined file,
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in the 2003-11-08
driver package in my VDR FTP archive.
So which is the one you tried in the 1.1.0 driver that had the same firmware
version?
I'm trying to help you: the
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in the 2003-11-08
driver package in my VDR FTP archive.
So which is the one you tried in the 1.1.0 driver that had the same firmware
On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in the 2003-11-08
driver package in my VDR FTP archive.
So which is the one
Andrew de Quincey wrote:
On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in the 2003-11-08
driver package in my VDR FTP
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build issue. I'm assuming your 2003-11-08 snapshot works for your
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build issue. I'm assuming your 2003-11-08 snapshot
On Saturday 20 March 2004 19:29, Helmut Auer wrote:
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So
its definitely not that; I just wanted to make ABSOLUTELY sure it
wasn't
Hello Klaus,
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
On Saturday 20 March 2004 16:42, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
From the Dpram checksums I can say that the first one is the one from
2003-09-05, and the second one is the one which is in
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't some
build issue. I'm assuming your
On Saturday 20 March 2004 21:15, Johannes Stezenbach wrote:
Andrew de Quincey wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as
the ones I extracted from dvb-ttpci-01.fw.gz currently on the
website. So its definitely not that; I just wanted to make ABSOLUTELY
On Saturday 20 March 2004 20:41, Andrew de Quincey wrote:
On Saturday 20 March 2004 19:29, Helmut Auer wrote:
I only tested for about 10 minutes now with switching hw_sections from 0
to 1 and vice versa.
It looks like diseqc is much better with hw_sections=0 !
Anyway once or twice it took
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as
the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So
its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't
some
build issue. I'm assuming your 2003-11-08 snapshot works for your
Andrew de Quincey wrote:
But why does it break DISEQC as well?
DiSEqC is implemented using a timer irq in the firmware.
And hardware section filters cause some ARM CPU load
(as do TS filters).
Of course, while tuning there is no signal and the load
should be zero. But some frontends just
Hello Andreas,
Andreas Share wrote:
Cool. The Root/Dpram in your 2003-11-08 DVB snapshot is the same as
the
ones I extracted from dvb-ttpci-01.fw.gz currently on the website. So
its
definitely not that; I just wanted to make ABSOLUTELY sure it wasn't
some
build issue. I'm
Klaus Schmidinger wrote:
From what I can see in the driver source, on AV7110 based cards
the actual DiSEqC signal is generated fom inside the firmware.
But since the firmware hasn't changed between the latest DVB driver
and dvb-kernel (at least as far as i know) I would assume that
the
On Saturday 20 March 2004 23:07, Johannes Stezenbach wrote:
Andrew de Quincey wrote:
But why does it break DISEQC as well?
DiSEqC is implemented using a timer irq in the firmware.
Well, this will work only if there is no other interrupt load.
Otherwise the timer interrupt processing
Andrew de Quincey wrote:
its not the firmware.
its not the frontend driver (that was a different issue).
well, pretty obvious where it has to be really; must be a card setup problem
in the OSS code. I'll have a closer check over the next few days.
Like I said before, DiSEqC was always
Andrew de Quincey wrote:
Ok, so I have changed the DiSEqC setup in my VDR to
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 9 H 10600 t V W15 [E0
The firmware that was originally on linuxtv.org for use with dvb-kernel
1.1.0 had version 0x261a, and thus was exactly the same as used in
dv-kernel 1.0.1.
So from what I can see the problem is definitely not in the firmware,
because with the exact same firmware the DVB driver works fine
Holger Waechtler wrote:
On Monday 15 March 2004 00:13, Klaus Schmidinger wrote:
Holger Waechtler wrote:
The DiSEqC spec requires you to set the appropriate bus voltage before a
DiSEqC command is sent. It also requires that the old-style SEC and
DiSEqC commands are sent compatibly,
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
On Sunday 14 March 2004 23:55, Andrew de Quincey wrote:
The problem with 1.1.0 is VDR isn't doing the full DISEQC init sequence,
and so no voltage was ever being sent to the LNB.
that's
Klaus Schmidinger wrote:
Ok, so I have changed the DiSEqC setup in my VDR to
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 9 H 10600 t V W15 [E0 10 38
Ok, so I have changed the DiSEqC setup in my VDR to
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
which
Hello,
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Holger Waechtler wrote:
On Sunday 14 March 2004 23:55, Andrew de Quincey wrote:
The problem with 1.1.0 is VDR isn't doing the full DISEQC init sequence,
and so no voltage was ever
On Monday 15 March 2004 17:55, Klaus Schmidinger wrote:
Ok, so I have changed the DiSEqC setup in my VDR to
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E
Hello Alfred,
Alfred Zastrow wrote:
---8-8-8-8-8-8-8-8-8-8---
S13E11700 V 9750 v [E0 10 38 F0]
^
this is nessesary to put power on the sat-cable.
The old driver had power on by default.
Good multiswitches with externel power
Hello,
S19.2E 11700 V 9750 v [E0 10 38 F0]
S19.2E 9 V 10600 v [E0 10 38 F1]
S19.2E 11700 H 9750 v [E0 10 38 F2]
S19.2E 9 H 10600 v [E0 10 38 F3]
S13.0E 11700 V 9750 v [E0 10 38 F4]
S13.0E 9 V 10600 v [E0 10 38 F5]
S13.0E 11700 H 9750 v [E0 10 38 F6]
S13.0E 9 H
From: Heino Goldenstein [EMAIL PROTECTED]
So this is what you have to do if you want to use DiSEqC only:
You forgot an important step:
- Put power on the sat-cable to wake up the switch
*WAIT* at least 100ms for the switch to power up, as per the DiSEqC
specification.
- Put DiSEqC-command
From: Heino Goldenstein [EMAIL PROTECTED]
Helmut Auer wrote:
These settings are not working for me, but the long version
from Oliver will:
S19.2E 11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0]
...
maybe your sat-cable does not transmit the DiSEqC-command reliable
and it
Hallo Robert,
Robert Schlabbach wrote:
From: Heino Goldenstein [EMAIL PROTECTED]
So this is what you have to do if you want to use DiSEqC only:
You forgot an important step:
- Put power on the sat-cable to wake up the switch
*WAIT* at least 100ms for the switch to power up, as per
Hi,
The diseqc settings:
S19.2E 11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0]
is not working perfectly. Sometimes when switching from h to v or vice
versa its not working.
Then I added W15:
S19.2E 11700 V 9750 v W15 [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0]
and this seems to work
Hi,
One ( hopefully ) last point:
It often happens after startup the first channel is not displayed by
vdr, that means, I have to switch once and the everything works fine. Is
that a vdr or dvb problem ?
--
Helmut Auer, [EMAIL PROTECTED]
--
Info:
To unsubscribe send a mail to [EMAIL
Helmut Auer wrote:
Hi,
The diseqc settings:
S19.2E 11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0]
is not working perfectly. Sometimes when switching from h to v or vice
versa its not working.
Then I added W15:
S19.2E 11700 V 9750 v W15 [E0 10 38 F0] [E1 10 38 F0] [E1 10
Helmut Auer wrote:
Hi,
One ( hopefully ) last point:
It often happens after startup the first channel is not displayed by
vdr, that means, I have to switch once and the everything works fine. Is
that a vdr or dvb problem ?
If DiSEqC switching doesn't work reliably I'd say it's a DVB
On Sunday 14 March 2004 10:27, Robert Schlabbach wrote:
From: Heino Goldenstein [EMAIL PROTECTED]
Helmut Auer wrote:
These settings are not working for me, but the long version
from Oliver will:
S19.2E 11700 V 9750 v [E0 10 38 F0] [E1 10 38 F0] [E1 10 38 F0]
...
maybe your
The two combinations below are working with the _unmodified_ ves1x93
code and also with my alps_bsvr2 mod.
S13E11700 V 9750 v [E0 10 38 F0]
S13E9 V 10600 v [E0 10 38 F1]
S13E11700 H 9750 v [E0 10 38 F2]
S13E9 H 10600 v [E0 10 38 F3]
S19.2E 11700 V 9750 v [E0 10
Andrew de Quincey wrote:
The two combinations below are working with the _unmodified_ ves1x93
code and also with my alps_bsvr2 mod.
S13E11700 V 9750 v [E0 10 38 F0]
S13E9 V 10600 v [E0 10 38 F1]
S13E11700 H 9750 v [E0 10 38 F2]
S13E9 H 10600 v [E0 10 38
On Sunday 14 March 2004 13:35, you wrote:
Andrew de Quincey wrote:
The two combinations below are working with the _unmodified_ ves1x93
code and also with my alps_bsvr2 mod.
S13E11700 V 9750 v [E0 10 38 F0]
S13E9 V 10600 v [E0 10 38 F1]
S13E11700 H 9750 v [E0
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
I get you, its the 'v'. Previously the driver was turning voltage on when it
started up, so power was being supplied, whereas now by default leaves it
off.
So this means VDR should turn the voltage _on_ upon startup, right?
I don't
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Andrew de Quincey wrote:
I get you, its the 'v'. Previously the driver was turning voltage on when it
started up, so power was being supplied, whereas now by default leaves it
off.
So this means VDR should turn the voltage
On Sunday 14 March 2004 23:02, Klaus Schmidinger wrote:
There are some mandatory delays before and after sending
the DiSEqC sequence. The Nokia API rolled all that in a simple
and convenient ioctl which would allow the driver to do
all the timing (so that applications cannot fuck up), but
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
It doesn't make much sense to remove the power from the LNB
while sending the DiSEqC sequence, but luckily vdr doesn't
seem to do that ;-) So, I guess that 'v' is a no-op.
'v' means voltage low (13V)
'V' means voltage high (18V)
On Sunday 14 March 2004 14:45, Andrew de Quincey wrote:
On Sunday 14 March 2004 13:35, you wrote:
Andrew de Quincey wrote:
The two combinations below are working with the _unmodified_ ves1x93
code and also with my alps_bsvr2 mod.
S13E11700 V 9750 v [E0 10 38 F0]
S13E
On Sunday 14 March 2004 13:11, Oliver Endriss wrote:
On Sunday 14 March 2004 10:27, Robert Schlabbach wrote:
From: Heino Goldenstein [EMAIL PROTECTED]
Helmut Auer wrote:
These settings are not working for me, but the long version
from Oliver will:
S19.2E 11700 V 9750 v
On Sunday 14 March 2004 22:22, Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
It doesn't make much sense to remove the power from the LNB
while sending the DiSEqC sequence, but luckily vdr doesn't
seem to do that ;-) So, I guess that 'v' is a no-op.
On Sunday 14 March 2004 22:27, Holger Waechtler wrote:
On Sunday 14 March 2004 13:11, Oliver Endriss wrote:
On Sunday 14 March 2004 10:27, Robert Schlabbach wrote:
From: Heino Goldenstein [EMAIL PROTECTED]
Helmut Auer wrote:
These settings are not working for me, but the long
Holger Waechtler wrote:
On Sunday 14 March 2004 23:02, Klaus Schmidinger wrote:
There are some mandatory delays before and after sending
the DiSEqC sequence. The Nokia API rolled all that in a simple
and convenient ioctl which would allow the driver to do
all the timing (so that
On Sunday 14 March 2004 23:22, Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
It doesn't make much sense to remove the power from the LNB
while sending the DiSEqC sequence, but luckily vdr doesn't
seem to do that ;-) So, I guess that 'v' is a no-op.
On Sunday 14 March 2004 23:35, Andrew de Quincey wrote:
If you specify a bus voltage of 13 or 18V you definitely don't mean
VOLTAGE_OFF but expect the LNBP working, everything else is a bug.
Yeah, it seemed to have changed from being set to VOLTAGE_13 in the
initialisation tables to being
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
It doesn't make much sense to remove the power from the LNB
while sending the DiSEqC sequence, but luckily vdr doesn't
seem to do that ;-) So, I guess that 'v' is a no-op.
'v' means voltage low
On Sunday 14 March 2004 22:36, Holger Waechtler wrote:
On Sunday 14 March 2004 23:35, Andrew de Quincey wrote:
If you specify a bus voltage of 13 or 18V you definitely don't mean
VOLTAGE_OFF but expect the LNBP working, everything else is a bug.
Yeah, it seemed to have changed from
On Sunday 14 March 2004 23:38, Klaus Schmidinger wrote:
When I compiled the latest VDR developer version with the dvb-kernel
header files, everything compiled just fine - so I would assume that there
was no change in the API (besides, it has always been emphasized that the
API did not change
When I compiled the latest VDR developer version with the dvb-kernel
header files, everything compiled just fine - so I would assume that there
was no change in the API (besides, it has always been emphasized that the
API did not change between DVB and dvb-kernel).
Sendeing DiSEqC codes in
Holger Waechtler wrote:
On Sunday 14 March 2004 23:35, Andrew de Quincey wrote:
If you specify a bus voltage of 13 or 18V you definitely don't mean
VOLTAGE_OFF but expect the LNBP working, everything else is a bug.
Yeah, it seemed to have changed from being set to VOLTAGE_13 in the
On Sunday 14 March 2004 23:46, Andrew de Quincey wrote:
On Sunday 14 March 2004 22:36, Holger Waechtler wrote:
As soon you submit the polarisation selection command (VOLTAGE_13V or
VOLTAGE_18V) you already powered up the LNB. The only important thing is
to maintain the delay times
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
Nokia specified the ioctl to run asynchronous, which causes
some headaches for implementation. The current API also
is more flexible and simpler, but forces every programmer
to scrutinize the DiSEqC spec to use it right. The old
API
On Sunday 14 March 2004 22:47, Holger Waechtler wrote:
On Sunday 14 March 2004 23:46, Andrew de Quincey wrote:
On Sunday 14 March 2004 22:36, Holger Waechtler wrote:
As soon you submit the polarisation selection command (VOLTAGE_13V or
VOLTAGE_18V) you already powered up the LNB. The only
Johannes Stezenbach wrote:
Klaus Schmidinger wrote:
Johannes Stezenbach wrote:
Nokia specified the ioctl to run asynchronous, which causes
some headaches for implementation. The current API also
is more flexible and simpler, but forces every programmer
to scrutinize the DiSEqC
Andrew de Quincey wrote:
On Sunday 14 March 2004 22:47, Holger Waechtler wrote:
On Sunday 14 March 2004 23:46, Andrew de Quincey wrote:
On Sunday 14 March 2004 22:36, Holger Waechtler wrote:
As soon you submit the polarisation selection command (VOLTAGE_13V or
VOLTAGE_18V) you
Hi,
On Sun, 2004-03-14 at 23:46, Andrew de Quincey wrote:
I suppose its a matter of how tolerant we want to be of userspace programs.. I
mean, we already turn OFF the LNB power automatically, why not turn it on as
well?
I don't care much, but please don't change the voltage setting in the
On Sunday 14 March 2004 23:45, Klaus Schmidinger wrote:
Holger Waechtler wrote:
As soon you submit the polarisation selection command (VOLTAGE_13V or
VOLTAGE_18V) you already powered up the LNB. The only important thing is
to maintain the delay times required by the spec, the diseqc.c
As of version 1.3.6 VDR explicitly turns on the LNB power at startup (which
I believe the driver should do when the frontend is opened), but that
didn't fix the actual DiSEqC problem (unreliable switching).
Odd. It seems to have fixed it for some people. I can't really do much else
I'm
On Sunday 14 March 2004 23:55, Andrew de Quincey wrote:
The problem with 1.1.0 is VDR isn't doing the full DISEQC init sequence,
and so no voltage was ever being sent to the LNB.
that's definitely illegal.
Holger
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with unsubscribe
On Sunday 14 March 2004 22:58, Johannes Stezenbach wrote:
- turn off 22KHz
- set voltage to 13V or 18V
- send DiSEqC sequence
insert 'send tone-burst' here
- if necessary turn on 22KHz
This sequence is defined in section 'Combined Transmission of DiSEqC
and Backward-Compatible Signals'. If
Andreas Oberritter wrote:
Hi,
On Sun, 2004-03-14 at 23:46, Andrew de Quincey wrote:
I suppose its a matter of how tolerant we want to be of userspace programs.. I
mean, we already turn OFF the LNB power automatically, why not turn it on as
well?
I don't care much, but please don't
On Sun, Mar 14, 2004 at 11:05:50PM +, Andrew de Quincey wrote:
On Sunday 14 March 2004 22:58, Andreas Oberritter wrote:
However, I don't like that idea. It makes it impossible to stay at 0V,
when the frontend is connected to a loop through output of another
receiver, which shall not
On Monday 15 March 2004 00:13, Klaus Schmidinger wrote:
Holger Waechtler wrote:
The DiSEqC spec requires you to set the appropriate bus voltage before a
DiSEqC command is sent. It also requires that the old-style SEC and
DiSEqC commands are sent compatibly, the behaviour of switches,
On Sunday 14 March 2004 23:15, Klaus Schmidinger wrote:
Andreas Oberritter wrote:
Hi,
On Sun, 2004-03-14 at 23:46, Andrew de Quincey wrote:
I suppose its a matter of how tolerant we want to be of userspace
programs.. I mean, we already turn OFF the LNB power automatically, why
not
On Monday 15 March 2004 00:27, Andrew de Quincey wrote:
So there must still be a change in the av7110 code, which does the DISEQC
on your card. As far as I can see none of the other changes to ves1x83
should break anything. Just that there were _two_ driver issues here
complicated the matter.
On Sunday 14 March 2004 23:31, Holger Waechtler wrote:
On Monday 15 March 2004 00:27, Andrew de Quincey wrote:
So there must still be a change in the av7110 code, which does the DISEQC
on your card. As far as I can see none of the other changes to ves1x83
should break anything. Just that
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101) driver
The 1.3 fails with the ves1x93(110) (polarisation switching)
The 1.3 fails
Andrew de Quincey schrieb:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101) driver
The 1.3 fails with the ves1x93(110) (polarisation switching)
The 1.3 fails with
On Saturday 13 March 2004 15:00, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101) driver
The 1.3 fails
On Saturday 13 March 2004 15:00, you wrote:
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101) driver
The 1.3 fails with the
On Saturday 13 March 2004 15:32, you wrote:
On Saturday 13 March 2004 15:00, you wrote:
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the
Andrew de Quincey wrote:
On Saturday 13 March 2004 15:00, you wrote:
Andrew de Quincey wrote:
OK, this is getting far too confusing. Need to summarise this:
We're trying two types of DVB-S-fullfeatured cards: the 1.3 and the 1.6
The 1.3 works fine with the alps_bsrv2(101)
Andrew de Quincey schrieb:
Index: linux/drivers/media/dvb/frontends/ves1x93.c
===
RCS file: /cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/frontends/ves1x93.c,v
retrieving revision 1.6
diff -u -r1.6 ves1x93.c
---
Alfred Zastrow schrieb:
Copy the alps_bsrv2.c and compat.h from the DVB-tree to build-2.4
Attached is a errorfree compiling diff against dvb-kernel from today
witch revivals the old alps_bsrv2 frontend driver.
If you want to use it, don't load the ves1x93.o.
For me it works pretty realible
On Saturday 13 March 2004 17:28, you wrote:
Alfred Zastrow schrieb:
Copy the alps_bsrv2.c and compat.h from the DVB-tree to build-2.4
Attached is a errorfree compiling diff against dvb-kernel from today
witch revivals the old alps_bsrv2 frontend driver.
If you want to use it, don't load
On Sat, 2004-03-13 at 19:12, Andrew de Quincey wrote:
Can someone try the attached patch (against CVS HEAD). It returns most of the
values to how they were previously. There are a few left changed, but I don't
want to go too fast.
in ves1x93_attach() 'state' is a local variable and you are
1 - 100 of 119 matches
Mail list logo
