thanks for the info.

thanks.
Now I see what I was missing.
Have not figure out what MSG_TYPE_CHANGED, MSG_DISCOVER, and MSG_UPDATE (#15, #1025, #1026) are used for yet.

ok, dumping the info into debug traces, I figured out that new call #16 is sending
struct dtv_property
(not dtv_properties, as I thought before).
And I'm able to forward this call to s2api-compatible dvb driver (via FE_SET_PROPERTY)

The only problem, VTUNER continue to send legacy FE_SET_FRONTEND commands.
It sends this legacy command immediately after last call #16.
Effectively ruining everything which was set-up by these #16 calls, because FE_SET_FRONTEND reverts delivery_system back to DVB_DVBS (at least in the v4l version which DMM uses for 2.6.18-7.4).

That is, all the current pumps (usbtuner, extuner, genpix_pump) do not work properly with USB DVB-s2 cards anymore (all DVB-S2 calls are replaced with DVB-s calls).

I edited my own pump (genpix_pump):
it does not pass FE_SET_FRONTEND requests from vtuner anymore, it replaces it with DTV_TUNE (via FE_SET_PROPERTY).
And now DVB-S2 USB cards are back in business.

But still, I don't know what call #17 is.
Is it important? or I can ignore it?

It would be nice if DMM will finally document the changes they made in vtuner in 2.6.18-7.4 kernel.
Cause all DVB-S2 USB tuner owners are left dead in the water.

Looks like VTUNER driver has changed during transition from 2.6.18-7.3 to 2.6.18-7.4 (that is, during transition to API5).

I see in the log that VTUNER is sending message with ID # 16 (10 times, just before the tuning attempt).
While in usbtuner (or extuner) all message IDs are defined only up to 14.
I guess, if #16 exists, #15 exist as well.

But these changes were not documented anywhere. At least I can not find any info.
Anybody knows where to look for this info?
and how to modify usbtuner/extuner to be able to work in 2.6.18-7.4 ?

Added:
Is this msg #16 the same as S2API is using to setup advanced properties of the tuning (FE_SET_PROPERTY)?
I also saw msg #17. Is it FE_GET_PROPERTY?

what's the format of the message? how "dtv_properties" is pushed into this msg?
is it something like this?

struct {
	int type;
	union {
		struct dvb_frontend_parameters feparms;
		fe_status_t status;
		__u32 ber;
		__u16 ss, snr;
		__u32 ucb;
		fe_sec_tone_mode_t tone;
		fe_sec_voltage_t voltage;
		fe_sec_mini_cmd_t burst;
		unsigned short pidlist[MAX_PIDS];
		unsigned char pad[60];
		struct dtv_properties; //  <--- new type of parameter for S2API tuning setup
	} body;
} msg;

then this msg #16 (if it's FE_SET_PROPERTY) should be called only once.
But it's called up to 10 times, as if it use "dtv_property" as a parameter (and not "dtv_properties"). That is, each S2API specific parameter is sent in a separate #16 message.

Can you please give som documentation on that?

simple copying of the content of
bitbake_folder/dm500hd/build/tmp/work/dm500hd-oe-linux/v4l-dvb-modules-0.0+hg20100904-r1/v4l-dvb/linux/drivers/media/dvb/dvb-core
into
bitbake_folder/dm500hd/build/tmp/work/dm500hd-oe-linux/linux-dm500hd-2.6.18-r7.1/linux-2.6.18/drivers/media/dvb/dvb-core
did not help.

Kconfig are way different and "make menuconfig" does not allow to select a driver anymore.
Had to fiddle with Kconfig files, hoping to do a "brute force" compiling.

And now I'm stuck with new functions not defined in standard 2.6.18 yet.
Like memdup_user() function call (used in dvb-core/dvb_demux.c)
This function was defined in later kernel versions (and declared in linux/string.h header).

Looks like string.h was back ported as well. But I can not find it (the one which is in bitbake_folder/dm500hd/build/tmp/work/dm500hd-oe-linux/linux-dm500hd-2.6.18-r7.1/linux-2.6.18/include/linux folder is old).

Do you have any tips on how to compile a modified dvb driver in YOUR environment?

added:
it would be probably more straightforward if I asked the simple question first.
I used to compile my dvb-usb-gp8psk.ko driver using dvb tree in (in older version, 2.6.18-7.3)
bitbake_folder/build-dm800/tmp/work/linux-dm500hd-2.6.18-r5/linux-2.6.18/drivers/media/dvb/

Now I made some backporting into dvb-usb-gp8pskto accommodate new s2api calls (and frontend.h definitions).
How do I compile it using your new v4l tree?
I tried to copy it into bitbake_folder/dm500hd/build/tmp/work/dm500hd-oe-linux/linux-dm500hd-2.6.18-r7.1/linux-2.6.18/drivers/
Obviously, it did not work.
What's the correct way to do that?

hmm, interesting.
Thanks for clarification.
I do see that bitbake_folder/dm500hd/build/tmp/work/dm500hd-oe-linux/v4l-dvb-modules-0.0+hgXXXXXXXXX-r1/v4l-dvb/linux/drivers/media/dvb/dvb-core contains patched dvb_ringbuffer.h and dvb_ringbuffer.h files.

Th fact that in bitbake_folder/dm500hd/build/tmp/work/dm500hd-oe-linux/linux-dm500hd-2.6.18-r7.1/linux-2.6.18/drivers/media/dvb/dvb-core I see already patched dvb_ringbuffer.h, but dvb_ringbuffer.c is still unpatched through me off my feet.
Somehow, the source code is partially patched in that folder (it's already not the same as in standard 2.6.18 tree).

I thought that source files will be patched in that folder (which I used) before the compilation.

I have a working gp8psk driver (it's part of dvb-usb) compiled in 2.6.18-7.3 environment.
and it works fine with DM500HD (and similar) receivers.

I tried to recompile gp8psk driver for a newer kernel version used in DMM images - 2.6.18-7.4.
And I can not. Compilation aborts on ringbufer functions use.

Looks like DMM changed dvb_ringbuffer.h and dvb_ringbuffer.c files in this latest kernel version.
But they provided ONLY header file (dvb_ringbuffer.h).
New dvb_ringbuffer.h file has different prototypes for the same function used in older dvb_ringbuffer.h.
As a result, dvb-core.o can not be compiled.
surely, I can not recompile my gp8psk driver (it depends on dvb-core).

Is dvb_ringbuffer.c going to be published?
and possibly all other changes in the code required to compile dvb-core.
Right now my compilation stops with this error:
dmxdev.c:101: error: too many arguments to function 'dvb_ringbuffer_read'
I don't know what else is wrong with the source after that.

PS: I tried to compile my driver against older dvb-core folder (which I copied from 2.6.18-7.3).
I was able to compile the driver, and even mount it. But as soon as I started usbtuner, kernel crashed.

did you mean 15ms tone-drop instead of voltage-drop?
Cause voltage-drop does not make sense (it's not required).

thanks, CTRL+F5 helped

After recent forum engine update, Firefox has a hard time to display forum pages properly.
A lot of text lines written over other lines (see the image). Which makes it impossible to read or even click on the link (because there two links are overlapped).
I can not even navigate to my own threads (which I started) to add more comments.
New layout is a disaster.

Anyway to make it workable in FireFox?

my intentions were to prevent a problem

Zitat von Olove

Okay, your assumtion is simply plain wrong.
TU1400 is a test header and no main connection.

huh?
what this has to do with what I was saying?
TU1400 may be a test connector, not a big deal. It does not change the conclusion which I stated above.
Check the positions of these connectors and the traces coming to them.
For instance, all traces from MPEG bus are coming to TU1400 first, and then (on the other side of the board) from TU1400 to TU1400_A.
Besides one power line (probably 3.3 or 5V) there are no traces which come directly to TU1400_A (and then from it to TU1400).

If you cut a trace (I'm not offering to do that, I just give an example of signal continuity) coming to TU1400, you will automatically loose a connection with TU1400_A (where tuner module is soldered).

One more thing which I forgot to mention (and which actually caused me to look into all this business with LNB line).
there is a rather wide trace between B2 pins of these two connectors (this is a width of trace which I expect to have for LNB line).
But the problem is: LNB voltage/current is supplied to tuner board through pin B1 (not B2).
B2 pin is physically connected to the circuit (of LNB controller) which is responsible for listening for Diseqc response from periphery (DSQIN pin of LNB controller; this is high impedance input).

That's why I ended up with a guess that someone set the widths of traces incorrectly (put a wide trace on diseqc feedback line, and narrow trace on LNB out line - it should be other way around).

PS: B1 and B2 pins are not shorted together (there is about 10kOhm impedance between them).

I'm talking about trace between pin B1 of connector TU1400_A and pin B1 of connector TU1400.
Tuner module is soldered into connector/socket TU1400_A, and LNB power is supplied through this pin (pin B1).

My assumption:
during design, TU1400 assumed to be a main tuner connector (for a raiser interconnection board, where plug'n'play tuner module is plugged in, as on all other DM models).
And pin B1 is receiving the power (through "beefy" line in some intermediate layer).
TU1400_A is a "back-up" solution (to solder a non-replaceable tuner module, instead of plug-n-play raiser board).
But someone who did a board layout forgot that trace between B1 pins should be a bit thicker then all other similar traces between these connectors (it's not just signaling line, it's a moderate current bearing line as well).

It's possible that there is a "back-up" trace between B1 pins in some intermediate layer.
But being a PCB designer myself, I know that most PCB design software packages "automatically" remove these duplicate traces during layout process. From my experience, there is more then 50% chances that this "back-up" trace does not exist.
Also, this backup trace in the inner layer should be twice as wide as the trace on the outer layer (cause inner layers use thinner copper slab, and passive heat radiation is obstructed by the insulator).
But I can not prove this without vandalizing the board. That's why I started the topic as a question (not an arrogant statement).

To be safe then sorry, I soldered a wire jumper between B1 pins on the back of my DM500HD main board.
Just in case....

PS: I don't encourage other users (who do not have soldering experience) to do what I did. You may ruin your board (and loose the warranty during this process).
If you have a heavy load on the other end of coax-cable, use power inserter (or powered switch). This would keep your warranty intact.

check this topic.
it may be that your failure is related to DM's hardware bug.
They routed very narrow trace from LNB controller to RF connector.
This trace is not enough to carry maximum current (which this LNB controller is capable of).
What's on the other end of your coax-cable (how heavy is the load?)?

I'm looking at the trace width coming from LNB controller to RF connector, and I think it's too narrow.

It looks like 3-4mil (75-100um) wide.
I'm not sure how thick the copper layer is.
But if it's standard thickness (1oz per square inch), rated maximum current for this width of trace is about 400mA.

I assume, software is limiting output current of LNB controller (it's LNBH21P) to 750mA.
For such current, trace should be at least 8mil wide (200um).

is it another hardware bug on DM side?

I just bought a brand new (at least, I paid for a brand new) DM500HD from authorized DreamMultimedia distributor in USA (there is only one such distributor in USA, and it's listed on DM web-site).
First of all, receiver came preconfigured for NTSC video output with some non-default settings in System Config.
It even had channels from two satellites in the channel database (European sats, not American, by the way).
That is, there were absolutely NO setup wizard during my first power up.
This is weird for a brand new receiver.

But this is not the end of the story.
Receiver was constantly freezing during my attempt to scan my satellites (froze picture with no responses to remote control).
I had to do reboot through power-cycling three times before I got couple of transponders scanned.
I decided to install the latest software version which I downloaded from this web-site (receiver came with preinstalled april's software version).
After software was successfully (as DreamUp said) copied from memory into flash, I am no longer able to boot this receiver. And I can not write any software into it either.

I opened the cover to see what's going on.
After inspection of the board, I found out that receiver uses REFURBISHED PCB. There are clear indication that board was damaged before, repaired, and then receiver was sold to me as a brand new unit. Repair was very unprofessional, mind you (check the photos). This could be the reason I it worked less then an hour on my end.

The question is:
do distributors know that they are selling refurbished units?
Should I be harsh with my distributor? Or they simply have no idea what they are selling (they sell whatever DM sends them)?

PS: i'm still angry at him, cause I still have not received reply on my e-mail question "how to return this crappy unit back to you?" I sent e-mail three days ago. And I left numerous messages on their answering machine.

OK.
what about modified question (from a person who kinda knows how to write drivers):
is there a way to write a DVB driver for USB tuner so it would work without vtuner interface?
Cause "generic_dvb_driver->vtuner" pimp is waaaaay slow (it takes about 40% of CPU time even on SD channel).

I understand, DMM guys are not interested in supporting third-party DVB cards, but do they have an alternative to genpix tuners (to offer similar capabilities)?

each DVB driver has its own time-out value for tuning (maximum time required to get a lock).
Some tuners have rather short time-out, others - relatively long.
This time-out value is returned by the driver (through fe_get_tune_settings() call).
And this value is hard-coded into the driver.

The problem with vTuner is: it uses it's own time out value (and it does not matter what a real time-out value is used in 3rd party tuner, connected to this vTuner interface).
As a result, vtuner aborts tuning before 3rd party tuner gets a lock (if that 3rd party tuner uses longer time-out then vtuner).
Particularly, genpix DVB driver uses 800ms as a min_delay_ms (while vTuner uses something shorter, like 400-500ms).
And very often vtuner reports "no lock" just because it does not wait long enough.

It would be a big help if vtuner would pass this time-out value (tune->min_delay_m) from "slave" driver (via additional command "MSG_GET_TUNE_SETTINGS").

in 95% cases, incorrect dish/switch/coax-cable grounding is the reason of intermittent diseqc switching.
It's getting worse when you have multiple receivers.
how many receivers do you have in the system?
You don't use DishPro/DishProPlus LNBs/switches, do you?

Do you have tuning problem if you bypass the switch?
This is important to know (to rule out tuner or LNB controller)

as far as I can see, LNB controller (the on which generates LNB voltage and is responsible for DISEqC commands) is not on the tuner module.
It's on the main board.

thus, if you have switching problem, mainboard has to be repaired.
If you have tuning problem, tuner module has to be repaired.

Zitat von tmbinc

Regarding the vtuner-interface, this is still in beta-phase, thus we are not officially supporting it. In case anyone has problems with it, feel free to write me a mail, but it's not yet a feature that is mature enough that it will be supported officially.

I was told (when I started to use vTuner when it was just implemented in DM software) that you can not close/re-open vTuner. You can open it only once, and if something went wrong with the pump (crash?), one has to reboot the receiver.

Has anything changed since then?
Is it possible to close vTuner now?
If not, do you plan to implement such features (it's painfully long to reboot the system after each software development iteration).