Geniatech hdstar 1f4d:3000

[NukeMania]

Hello,
I tried your Montage-3103b.v2 patches on geniatech hdstar but Kaffeine and dvbv5-scan got errors like diseqc tx timeout, invalid fec_inner, invalid rolloff and out of range (950000..2150000)

dmesg log
https://pastebin.com/qa6GVWkC

[b-rad-NDi]

oh hey wow, this issue totally slipped through the crack! Apologies

[b-rad-NDi]

You get so much spew from the demod driver without enabling any debug?

[b-rad-NDi]

And do you mean errors were output, but things still worked, or errors and does not work?
We've tested this driver on Hauppauge devices on all sorts of platforms and it works fine. I'm no expert with this class of devices and have no way to test dvb-s first hand.

[NukeMania]

you don't have to apologize we all have a life outside it's ok :)
I load the module with dyndbg=+pt option I didn't build with debug but I thought I made a mistake when others didn't come with similar errors. never tried again

No signal and no scanning just errors I tried without diseqc but still same

[davidryderuk]

Hi,

I have a Geniatech HD Star which was purchased sometime in 2018, which I believe is the same device NukeMania is using. I downloaded the Montage-3103.v2 branch from this repository and wrote a patch to force the dw2102 driver to use the m88ds3103 driver, if probing the device using the older ds3000 driver failed. The patch is based on the one Brad used to add support for the 'Hauppauge 461e rev2', with minor changes to account for slightly different data structures within the dw2102 module, as well as using the platform data from the 'TechnoTrend TT-connect S2-4600', rather than the 'Hauppauge 461e rev2'. I'm not certain I've used the correct platform data, but I've testing the code for 2 - 3 days, and everything seems to be working correctly. Overall things seem to be more reliable than with the ds3k driver from CrazyCat's linux-media kernel, with less continuity errors. The only other thing to note is my copy of Ubuntu didn't have the required firmware, so I acquired it from a CoreELEC repository.

Please note I'm not a kernel developer and I'm far more comfortable programming in Python than C. I just thought it was worth posting my findings somewhere on the internet, and this seemed as good a place as any.

dmesg:
https://pastebin.com/y36vM8Nz

patch:
https://pastebin.com/MM2RcKsh

[NukeMania]

i am totally devastated :lol my device still got same errors but I found the root cause of errors
@davidryderuk For some reason my device is little a different than yours and with my patch or your patch I got same errors
Firmware won't load on device even if I delete firmware file it won't alert the "firmware file '%s' not found\n", name);"

[davidryderuk]

@NukeMania
Maybe double check the ds3k driver is using the '0x6a' address for accessing the demodulator? If you read the code in the ds3k driver it seems to check all the addresses between 0x68 and 0x6b and use whichever one returns the correct value. You could add a quick printk statement to the ds3k driver to check which address is being used. Other than that, I'm out of ideas, sorry.

From the ds3k_attach function:

/* check if the demod is present */
for(i = 0x68; i <= 0x6b; i++) {
  state->config->demod_address = i;
  ret = ds3k_readreg(state, 0x00) & 0xfe;
  if((ret == 0xE0) || (ret == 0xE8 ))
    break;
}

/* Suggested printk statement
printk("demod_address is 0x%02x", state->config->demod_address);

[NukeMania]

@davidryderuk
thanks for help but demod_addr is 0x6a also it's hard coded in dw2102.c
maybe chip version is different mine is 0.161
can i ask for one last thing
could you build ds3k with debug enabled (debug = 1; and debugI2c = 1; in ds3k.c)
and if you could send dmesg log I want to check if there are differences

thanks

[davidryderuk]

@NukeMania
This is with the ds3k driver and kernel version 5.2.0 rc7.

https://pastebin.com/LzGjS0RZ

[NukeMania]

@davidryderuk
thanks for your log
my device's tuner has a different id than yours : 0xc3 mine: 0xc1 and demod's attach part is different
errors are probably related to incompatible tuner
https://pastebin.com/9BBiDW76
I'm closing the report it is not related to this branch

[NukeMania]

@b-rad-NDi I hope you don't mind I re-opening bug report again. some of other users reported as not working so I can test if the fix comes

[b-rad-NDi]

The more testers the merry. The reason development on this halted is a plain and simple lack of anyone giving me feedback. I appreciate anyone willing to help test.

[NukeMania]

as I understand the problem you're dealing I think there are two different produced batches of m88ds3103b and there are incompatible between each other
I don't know also affected to hauppauge 461e devices but
its confirmed with geniatech hdstar if you want to see the example above of bug report
one of geniatech hdstar works with current branch of Montage 3103b.v2
but my device is not working with Montage 3103b.v2
also vendor driver is not working well too on windowz system :)
only hauppauge WinTV-NOVA SAT (Model 139000) driver works perfect

all those my opinion of course i may be wrong

[b-rad-NDi]

I got an email today from someone about how happy they are my branch worked with their terratec cinergy. So, I'm not sure why, but at least some configurations work. Now we just have to make everyone happy.

[NukeMania]

I compare ds3k and m88ds3103b i2c traffic thery are quite different
https://pastebin.com/ZpVKQUPe
https://pastebin.com/savF5uvz
debugging a dvb device harder than i thought
can you tell me any suggestions How can i identify the cause

[b-rad-NDi]

Do you own a 461e v2? If you do the solution to the problem was as easy as me forgetting to commit some bridge driver defaults as I tested every combination trying to figure out how to make them work.

Check out the other issue on this repo or check the commit in a bit that sorts out the defaults.

[b-rad-NDi]

Driver updates have been migrated to branch:Montage-3103b.v3

Note this contains an update to get closer to upstream, an i2c dummy device for the timing chip. If you compile and find this modification does not work, it can be backed off by switching which line in commented in the dt_read/dt_write functions.

[NukeMania]

I don't have a 461e v2 I have a weird version of geniatech hdstar :) everybody's device is working with your tree source but except mine still refuse to work lol
I am pretty sure ı do have diffirent version of m88ds3103b chip
my guess is my device refuse to work in parallel mode also it didn't work with vendor driver in parallel mode too (ds3k)
only CI mode working
but with Montage-3103b.v2 just a moment I got a frame of picture(worked just one second) thats my success :))
rest of my tries are out of luck
Montage-3103b.v3 way better only i2c errors and diseqc tx timeout errors

I did build your tree with debug options enabled but debugging a dvb device harder than i thought
can you tell me what kind of logs you need the determine problem

[b-rad-NDi]

To be honest I might have completely ignored serial mode, because I don't have a device that operates that way. It's very likely that a 3103b set up in serial mode will not work at all. I have noticed that 3103b uses values that are more similar to CI mode values for 3103 chips.

I'm no satellite expert and barely know anything about these chips, but, if you generate minimal logs with full debug enabled I'll take a look. By minimal I just mean not tens of thousands of lines of w_scan results, just szap (or whatever) or other similar minimal usage that displays the non-working.

[NukeMania]

I will try my best for minimal logs
also in past I did in dirty way parallel to CI conversion on your patches but it didn't work but I will try again for Montage-3103b.v3
but if you need a device profile similar to mine you can look into hauppauge WinTV-NOVA SAT (Model 139000) vid_2040 pid_d901
only hauppuage's windows driver that works perfect with my device even geniatech driver has serious problems with my device (geniatech linux driver shares same issues too)

[NukeMania]

i can't get debug logs nor tracing too also I did enable "CONFIG_DVB_USB_DEBUG:"
enabling debug level on dmesg won't help either but there are too many i2c errors (i2c read request failed: i2c status 7)

is there a tutorial that how do I get debug logs

[b-rad-NDi]

Look up dynamic debug, there's lots of information. You don't have to compile anything special into the kernel as long as dynamic debug is enabled. You just have to tell the kernel which files to enable output for. Turn it on for m88ds3103.c and anything else you desire.

[NukeMania]

here are the logs
https://pastebin.com/sZFUY5Db -> dynamic log
https://pastebin.com/cZCC0V9r -> m88ds3103 loaded with dyndbg=+pt option

[b-rad-NDi]

I know nothing about dw2102 driver and it seems to be who is spitting out all the errors.

[davidryderuk]

Hi,

I thought it would be helpful for me to test the Montage-3103b.v3 branch, since my Geniatech HD Star device is similar to the one being used by NukeMania, if not exactly the same. I compiled the branch, and as before I patched the dw2102 driver so that it would use the m88ds3103 driver, since by default it seems to use the ds3000 driver instead. There are a few things that are potentially worth noting:

1. A different version of the firmware is being used (3.7 vs 4.1). How do I get version 4.1?
2. The i2c read request failure occurs on my device as well, with both devices behaving in a similar manner, at least according to the log, until the point where the m88ds3103 driver tries to call the 'm88ds3103_set_mclk' function (i.e. where register 0x0d is mentioned in the log).
3. It looks as though the dw2102 driver is passing results back to the m88ds3103 driver, even after the 'i2c read request failed' message, which seems a bit odd. On the other hand the driver presumably would have done the same thing before commit 5d04005, just without the warning.

Patch for dw2102 driver:
https://pastebin.com/MM2RcKsh

dmesg from initial loading of device through to getting a signal lock:
https://pastebin.com/qnf6et8E

[NukeMania]

@davidryderuk
you're correct mine is not exactly same as yours (i have compared previously both ds3k logs)
some how my demod and tuner different my guess is those are early revisions or something like that
firmware 4.1 : https://github.com/OpenELEC/dvb-firmware/blob/master/firmware/dvb-demod-m88rs6000.fw

may i ask you could you send me a picture of inside the box also could you tell me on demod and tuner what written on those chips

[NukeMania]

clearly my device has different version of m88ds3103b and it operates slightly different
other ds3103b identity value is 0x80 mine is 0x73
probably i got a device as older or pre production

[b-rad-NDi]

Without data sheet and/or a working driver to compare i2c traffic against I'm afraid I can't help you. I really know nothing about this demod. I reverse engineered this code in the dark to determine the pieces to extract.

Also to make dynamic debug more useful you should only use option: +pfl (print + function + line number)

[NukeMania]

thanks I know you trying to help but you don't have much data/knowledge of chip
here is compare between two different m88ds3103b logs of ds3k driver
https://docs.google.com/spreadsheets/d/12-xnLNyZyf8yjs19C6LNnl9jgVYxJirHbrtPE4aTavk/edit?usp=sharing

those are dynamic logs first attempt and second attempt
I have to wait a day for another try (lol) no matter what if I wait less than a day it won't load firmware otherwise I know it's weird but it's true

https://pastebin.com/XF6zs4sG cold boot first connect > firmware loading ok
https://pastebin.com/Tbx69yf7 re-plugged second connect > firmware version=FF

[davidryderuk]

To confirm, firmware versions 3.7 and 4.1 appear to behave the same way on my device. I don't have much experience at taking apart hardware, I would be a bit worried about the possibility of not being able to put the device back together again, or damaging it, so I don't have any photos of the chipset.

I have been trying to compare the code for the ds3k and m88ds3103 drivers, along with your logs, since the former seems to work better, in the sense that you are at least able to tune the device some of the time (correct me if I'm wrong). A lot of the differences just seem to be due to a different programming style, as far as I can work out. One difference I noted was that whilst both drivers sleep, at various points in the code, the ds3k driver uses the 'msleep' function, whereas the m88ds3103 driver uses the 'usleep_range' function. Since the two functions depend on two different timing mechanisms, this means that the ds3k driver could potentially be sleeping several times longer longer than the m88ds3103 driver, especially in cases where the requested sleep interval is less than 20ms (see here). Therefore the difference between the two drivers could be due to a difference in the amount of time they wait, after changing the tuner's configuration. I appreciate it is a bit of a long shot, but maybe you could check whether or not getting the m88ds3103 driver to wait a bit longer makes any difference?

https://pastebin.com/6B0pDS8S

[NukeMania]

I already tried in past changing sleep intervals it didn't work but to be make sure for your patch I did try again it didn't work too
3 times I got a picture for one second in initial tune but randomly happened
I collected the i2c traffic logs of three different windows driver and also ds3k and m88ds3103 logs too
but they all operates the device differently unfortunately i can't locate the problem
I out of ideas I gave up already

[NukeMania]

@b-rad-NDi
Hello again :( after a long break lucky me i found the problem :lol
my tuner requires to work with TS2020_CLK_OUT_ENABLED_XTALOUT option and M88DS3103_TS_PARALLEL mode

i didn't test CI mode yet(edit:it doesn't work with CI mode) but with those configs device works almost perfect I just encountered one problem with disecq, only first port works with kaffeine (edit: all ports of disecq only working with tvheadend)

device can even lock 16apsk 85mbit & 8psk 70mbit transponders
with vendor driver i can only lock those transponders if i reboot from windows without disconnecting the device (only hauppauge driver works vendor's windows driver also can't lock those transponders too)

also vendor's linux driver sets ts_clk to 6000 but my device works with 16000 better than 6000
also device works better with vendor's register values and 4.1 firmware

but still i got a couple failed in logs and if i use standart register values sometimes it gonna fail to first lock
https://pastebin.com/pU8W6qFi
https://pastebin.com/J6RbvGeD

thanks for bringing ds3103b support

edit:
for those who wonder why it took so long to understand the simple problem because i didn't pay attention the logs in beginning
i was sure loop_through values(0x42,0x6c) were different from others but those values are similar to clk_out values(0x62,0x6c) that's why I got confused before all time with loop_through
i didn't notice my tuner has different clk_out until today

edit2: when i start using m88ds3103 module,in windows after short usage device stop working
I will continue to use the vendor driver for a while until I find the problem.

last edit: device working fine with those ts2020 configs
now i can close the bug report :)
ts2020_config.clk_out = 2; ts2020_config.loop_through = 0; ts2020_config.get_agc_pwm = m88ds3103_get_agc_pwm;

really the last one edit :)
i found the cause of windows driver freeze issues i have to disable clock output of demod :lol
m88ds3103_pdata.clk_out =M88DS3103_CLOCK_OUT_DISABLED

[b-rad-NDi]

@NukeMania : can you contact me regarding these modifications you are suggesting? If you need me to modify something upstream to support your use case I will gladly advocate for your requirements.

[NukeMania]

@b-rad-NDi
I am grateful for your willingness I sent a mail to you i didn't wanna mess with github comment section mail is a little longer
i am sorry for having to you deal my bumpy english

thanks,