Jump to content


Photo

satellites.xml is wrong !


  • Please log in to reply
64 replies to this topic

#1 jpuigs

  • Senior Member
  • 1,143 posts

+32
Good

Posted 15 August 2018 - 22:40

What is happening with satellites.xml ???  Transponders appear totally unsorted.

The last two updates, on August 9th and 13th are the wrong ones.

 

 


Enigma is getting old....

 

Spoiler

Re: satellites.xml is wrong ! #2 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 16 August 2018 - 08:48

There is already a thread running about satellites.xml listing the defects. WanWizard is in the process of sorting it out.

Re: satellites.xml is wrong ! #3 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 16 August 2018 - 09:04

Thread here: https://forums.openp...common-updates/



Re: satellites.xml is wrong ! #4 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 16 August 2018 - 09:15

List of known problems,

 

1) Something is failing when reading FEC. 129.0W is a good example of a major failure to read FEC but it is a common problem in the file currently on the repo.

2) Some transponders are completely missing. e.g. 121.0W, 11990H, 12016V. Not sure if this is intetional but I'm guessing not.

3) You are replacing "&" in the satellite names with "..". Should be "&".

4) Something weird going on with the satellite names. Lyngsat: "Star One C1 & Eutelsat 65 West A", satellites.xml: "Eutelsat 65 West A..Star One C1".

5) 61.0W, transponders not listed in frequency order, nor Lyngsat order, may be the same on some other satellites, e.g. 3.0E has the same problem.

6) Transponders missing when the frequency exists on more than one beam. e.g. 4.8E, Sub-Sahara 11747 V 27500 and Europe BSS 11747 V 30000. (On closer inspection it seems to be tagged on the end, but the frequency order is a mess).

7) -08 and -09 have a leading zero.

8) West slots are not in natural order e.g. -9 should come before -8.

9) Root PLS codes could be converted to Gold as this is enigma default.

The above problems seem to be recurring throughout the file. While they are there it makes it hard to run a diff on it to find other problems.

 

Python code to convert the PLS codes:

def gold2root(gold):
	if gold >= 0x3ffff:
		print "[gold2root] gold code invalid %d, returning default.\n" % gold
		gold = 0;
	g = 0
	x = 1
	while g < gold:
		x = (((x ^ (x >> 7)) & 1) << 17) | (x >> 1)
		g += 1
	return x

def root2gold(root):
	if root > 0 and root < 0x40000:
		g = 0
		x = 1
		while g < 0x3ffff:
			if root == x:
				return g
			x = (((x ^ (x >> 7)) & 1) << 17) | (x >> 1)
			g += 1
		print "[gold2root] input invalid %d, returning default.\n" % root
		return gold2root(0x1); # when input is wrong just return default gold value


Re: satellites.xml is wrong ! #5 jpuigs

  • Senior Member
  • 1,143 posts

+32
Good

Posted 16 August 2018 - 14:32

thanks, eggs   ;)


Enigma is getting old....

 

Spoiler

Re: satellites.xml is wrong ! #6 WanWizard

  • PLi® Core member
  • 68,617 posts

+1,739
Excellent

Posted 16 August 2018 - 14:35

Yup, busy with it, but travelling, so not a lot of time in the next few weeks.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: satellites.xml is wrong ! #7 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 18 August 2018 - 08:53

Do I hear a volunteer to update our (Python) grabbing script? ;)


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: satellites.xml is wrong ! #8 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 18 August 2018 - 09:05

Do I hear a volunteer to update our (Python) grabbing script? ;)

 

Well I asked here: https://forums.openp...-updates/page-3 nobody responded ...


Open Vision sources: https://github.com/OpenVisionE2


Re: satellites.xml is wrong ! #9 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 18 August 2018 - 09:21

That thread was poisoned by a certain person. I don't think we can make the grabber public, I think we need to discuss that internally.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: satellites.xml is wrong ! #10 WanWizard

  • PLi® Core member
  • 68,617 posts

+1,739
Excellent

Posted 18 August 2018 - 10:51

Well I asked here: https://forums.openp...-updates/page-3 nobody responded ...

 

I responded. With "it is not my decision to make..." ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: satellites.xml is wrong ! #11 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 19 August 2018 - 13:20

PR to "fix" currently broken version until grabber gets repaired if OpenPLi team cares to use it.

https://github.com/O...343c2ba2361018c



Re: satellites.xml is wrong ! #12 arkovda

  • Senior Member
  • 45 posts

0
Neutral

Posted 19 August 2018 - 15:21

the file uploaded 2 hour ago is not complete, at the very end it does not end with </sat> so "138.0E C-band Telstar 18" probably won't work

/Arkovda



Re: satellites.xml is wrong ! #13 jpuigs

  • Senior Member
  • 1,143 posts

+32
Good

Posted 19 August 2018 - 20:11

PR to "fix" currently broken version until grabber gets repaired if OpenPLi team cares to use it.

https://github.com/O...343c2ba2361018c

 

Thank you very much.


Enigma is getting old....

 

Spoiler

Re: satellites.xml is wrong ! #14 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 20 August 2018 - 01:37

the file uploaded 2 hour ago is not complete, at the very end it does not end with </sat> so "138.0E C-band Telstar 18" probably won't work

/Arkovda

File in the PR is complete.



Re: satellites.xml is wrong ! #15 WanWizard

  • PLi® Core member
  • 68,617 posts

+1,739
Excellent

Posted 20 August 2018 - 10:25

I can't merge the PR anymore, as the grabber runs on monday's. Can you update it? I've stopped the cron job to avoid a repeat.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: satellites.xml is wrong ! #16 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 20 August 2018 - 12:54

OK. There is another PR here.

 

https://github.com/O...box-xml/pull/11

 

Also I notice OpenPLi uses flags="1". Personally I would avoid this as the user can decide anyway in the scan screen. Currently that is network="yes" for a full satellite scan and network="no" for a single transponder scan.



Re: satellites.xml is wrong ! #17 WanWizard

  • PLi® Core member
  • 68,617 posts

+1,739
Excellent

Posted 20 August 2018 - 13:05

Thanks, merged.

 

Nu clue what "flags=1" means, I would have to dive into the code for that.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: satellites.xml is wrong ! #18 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 20 August 2018 - 19:32

Flags=1 means NIT scan. But anyway that is controlled from the scan screen as a user option.

Re: satellites.xml is wrong ! #19 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 21 August 2018 - 20:51

Hi,

Question: Why "Chinasat 12" position is 876? https://www.lyngsat....hinaSat-12.html

I was expecting 875 (since this sat is not multi-band).

	<sat name="87.5E C-band ChinaSat 12" flags="0" position="876">
		<transponder frequency="3774000" symbol_rate="1800000" polarization="0" fec_inner="3" system="1" modulation="1" />
		<transponder frequency="4006000" symbol_rate="1100000" polarization="0" fec_inner="3" system="1" modulation="2" />
		<transponder frequency="4035000" symbol_rate="1200000" polarization="0" fec_inner="3" system="1" modulation="1" />
		<transponder frequency="4140000" symbol_rate="28800000" polarization="1" fec_inner="3" system="1" modulation="2" />
	</sat>
I though that position was changing on multi band satellites.

Eg.
1. When C,Ku,Ka then Ku then C +1/-1 and then Ka +1/-1 (meaning Ku = 60, C = 61, Ka = 62)
2. When C,Ka then C and then Ka +1/-1 (meaning C = 60, Ka = 61)
3. When L,S,C,Ku,Ka ?

Generally, what is the order in multi-band satellites? Ku, C, Ka, S, L?

Is there a generic rule if C then +1/-1, if Ku then +2/-2.

Do we have L,S band available? I don't see any.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: satellites.xml is wrong ! #20 Huevos

  • PLi® Contributor
  • 4,247 posts

+158
Excellent

Posted 21 August 2018 - 23:45

Hi Athoik,

 

My logic is always +1 for C-band east and -1 for C-band west irrespective of whether it is multi-band. Reason for this is because when ku-band transponders get switched on/off we don't want that to cause the C-band position to change and break people's settings. One example is 40.5W. That was a C-band position. Then Ku-band signals were added in 2015. If there wasn't a forced -1 the position would have broken resulting in greyed out channels. My version has been like this for more than 5 years and no one has complained. Hundreds of copies are downloaded everyday.

 

What would be better would be if enigma was fixed so we could put all bands under the same satellite on a single position. Means we need to be able to configure multiple LNBs on a single position which is currently not possible.

 

Then Ka-band is +2 for east and -2 for west. I only added Ka-band to mine a couple of days ago. No one has ever requested it.

https://github.com/o...90912e1339c3b92

 

What frequencies are L and S? I can search the DB.

 

One other thing, my positions on most of the European satellites are held stable by the download script. So if Lyngsat moves a satellite from 4.8E to 4.9E my script will still build it as position "48". Satellites can move up to 0.25º before they lose their fixed position. This means as satellites wander about by a couple of tenths of a degree users settings are not broken by a satellites.xml update.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users