Multiple Unicable systems / virtual diseqc (-A) and unicable (-u) ? #1174
Comments
|
I've resorted to using -S myself, even though it's not optimal. I think what you're describing isn't possible with the current code, even though the hardware should support it. You could try ancient builds of perexg/satip-axe to see if you find a version where everything works, then we could work from there to get the changes incorporated into master again. |
|
I don't think even the perexg builds do quite what I'm asking for. The dist/minisatip.md file included in the perexg build mentions an "-X / -9" option that deals with multiple Unicable groups but that appears to effectively partition the device into two or more groups.
My reading of the above is that tuners 0 and 1 will be constrained to input 0, and tuners 2 and 3 will be constrained to input 2. In any case, the perexg patches that enable the above functionality were introduced in build 11 which so far as I can tell (I'm not a git expert) had the patch files stored in an external filesharing service that is no longer operational. Thinking about this a bit more, a new implementation should take into account situations where the two separate Unicable systems need to use different user bands. I shall ponder for a bit and see if I can come up with a sensible design / configuration syntax. It feels like it could get very complicated. |
Actually, scratch what I said there. A bit more learning of git and I came up with this: https://github.com/perexg/satip-axe/tree/572269b |
|
Hi @mark-royds , I hope you could fix your problem, as I've the idea of moving my current infrastructure to unicable with mutiple sat positions. And I feel your problem needs to be fixed. But in any case, I suggest a more complex alternative: put DiseqC 1.0 switchess before the unicable cables. Then instead of two tuners fixed for each sat position, you'll have the option of using each tuner with the two satelital positions. That's my idea: This requires two wires for each LNB, and four new small switches. Easy to add. But then minisatip requires to process first the command to change the DiseqC swith and after send the Unicable command. What you think about this? |
|
Hi @mark-royds ,
After reading with more detail your description, I recommend to first do the test with only 2 tuners: 0 and 1, each connected to one wire. After that check this please: So if this test will complete, then we can try to add the other two tuners. But for this, before configure internally the AXE device, I'll recommend to use a single wire spplit to connect two tuners to the same wire. It will be more easy to isolate the problems. Please inform us with your new results. |
|
Hi @lars18th I've just tried the solution you proposed. Unfortunately, ommitting the Results Some logs of minisatip startup: The first part of the logs for a tune request with In the logs you can see So minisatip is using the 4th slot defined in the |
This would require the purchase of (4) switches and (2) 4-way splitters (I only have one cable available from each LNB).
Unicable/Jess is also using DiSEqC to command the LNB. Is that an issue? |
Yes, in your case, I feel is the best option. |
Hi @mark-royds , The parameter |
|
My understanding is that I think that's the crux of the problem really. The adapter (read: FE) should really not matter. The critical variable is the physical input. My R1 is in a remote location so I can't switch the cables over just now . I currently have it wired with LNB-A in input 0 and LNB-B in input 3. Using |
|
Perhaps what we need is Something like that anyway... perhaps include some way to specify Legacy/Unicable/Jess at the same time. I suppose DiSEqC would need to go in there too. A bit unwieldy perhaps |
|
I'll think this over some tomorrow |
|
Hi to all, After more thinking on this issue I've these comments:
What do you think? |
|
Is the I'm snowed under with my day job for the next couple of days but if I get a moment I'd like to document the behaviour in legacy LNB mode. I'm recall that I've been able to have minisatip route any FE to any physical input by passing The elephant in the room is the possibility of each Unicable/Jess system using different user bands. Technically it should be possible to use a simple RF combiner to join multiple systems to the same physical input and have the appropriate LNB triggered based on the UB requested by the FE. However minisatip doesn't have any command line option that I can see where you can link SRC,UB & physical input together. Perhaps we should draw up a complex theoretical test system and identify any gaps in minisatip functionality, I don't write good code, but I can do good analysis so would be happy to put my hat in the ring for that. |
|
Hi @mark-royds , The question of driving "complex" unicable configurations is now out the scope. This include "multiple unicable LNBs in the same wire with not overlaped user bands for different satellite positions". But also other configurations, for example "different unicable LNBs each one in one different wire connected to a switch in front of the tuner". This is more or less what you have, but in this case the switch is internal and not managed by diseqc commands. This will need to be targeted in the future if someone wants to implement it. But I feel that your current problem could be fixed without implementing something new, because your unicable LNBs are equal and using the same user bands. |
|
Hi @mark-royds , I feel you need to try the @Jalle19 version of AXE: https://github.com/Jalle19/satip-axe Please read: https://github.com/Jalle19/satip-axe/blob/master/dist/minisatip.md#multiple-unicable-groups |
I have seen that version but there are a couple of issues...
|
Personally I think if there is an effort to implement something that will fix my issue, it's worth designing a solution that widens the scope a little so that some other edge cases can be picked off too. My rationale is that the problem I have seems to stem from an limitation in the implementation of Unicable/Jess. Rather than create a very targeted patch for one (my) use case, perhaps better to address the underlying limitation for the benefit of a wider group. As I say, I'm happy to investigate and specify a more complete solution but my middle name is segfault so I would need the help of someone with much more coding skill when it comes to the implementation.
This is useful information. Is it i2c or something? |
|
Hi @mark-royds , Unfortunately, I can't help directly because I don't use AXE. And for this reason I suggest to target your problem without much changes. Your device has an internal switch that is controlled with the I2C bus. Therefore is not standard. More or less your configuration is a "cascade" of a switch+unicable. And it works because the internal switch is independent and it could be controlled without diseqc commands. But in any case, the "grouping" support is necessary. Please @Jalle19 could you review your PR #979 ? I feel the issue from @mark-royds is related. |
|
It's related, yes. I haven't had time to debug this any further. |
|
Hi @catalinii and @Jalle19 , Based on the configuration commented by @mark-royds , I want to discuss about this use case:
At time we don't have support for this configuration. Any idea to support it? |
I am having difficulty finding the correct configuration to support an environment with 2 separate unicable LNBs.
I'm using a Digibit R1 (idl4k) device that has 4 physical inputs (numbered 0 - 3), 4 frontend tuners (0 - 3), and an internal switch that allows any input to be routed to any tuner.
With only had a single LNB connected, everything works well.
Physical input 0 connected to a Unicable LNB pointing at constellation A.
I used "--unicable 0:0-1210,1:1-1420,2:2-1680,3:3-2040" to start minisatip and as expected, a tuning request for any FE is routed to the LNB on port 0.
I now want to add a second constellation:
Physical input 3 connected to a Unicable LNB pointing at constellation B.
The Unicable user bands/frequencies for the 2nd LNB are the same as those used on input 0.
What is the correct configuration to support the the above topology?
"-A 0:0:0,1:3:0" doesn't seem to work as expected - tune requests for constellation B (src=2) are still routed to input 0.
The closest I've been able to get is by adding "-S 3:3". This forces frontend 3 to use input 3. However, this means FE3 always uses input 3 and prevents access to input 0 - requests for fe=4&src=1 are still routed to input 3.
The results of all my testing are as follows:
config request result-A 0:0:0,1:3:0 fe=1&src=1 OK - FE0 connected to input 0-A 0:0:0,1:3:0 fe=4&src=1 OK - FE3 connected to input 0-A 0:0:0,1:3:0 fe=1&src=2 FAIL - FE0 connected to input 0-A 0:0:0,1:3:0 fe=4&src=2 FAIL - FE3 connected to input 0-S 3:3 fe=1&src=1 OK - FE0 connected to input 0-S 3:3 fe=4&src=1 FAIL - FE3 connected to input 3-S 3:3 fe=1&src=2 FAIL - FE0 connected to input 0-S 3:3 fe=4&src=2 OK - FE3 connected to input 3Testing was carried out with version 1.2.1 and 1.3.23 with identical results.
This seems to be an issue specific to Unicable and Jess. If eliminate the unicable configuration and fall back to legacy tuning, the above tests all pass. Of course, legacy tuning is only 25% useful with a single cable drop from each LNB as in this case.
The text was updated successfully, but these errors were encountered: