I'm one of the folks over at Schedules Direct.
We've (I've) been working on a lineup for Free-to-Air for our new JSON data service for scheduling. Since I don't have a FTA system, I've been trying to deduce what's important and what's not.
Since we're still in beta, I'm trying to ensure that our FTA lineup has the information that's actually required / useful, so we're soliciting feedback. If something like "FEC" or symbolrate isn't important to anyone, and no application or tuner actually uses it because it's all "auto", then it doesn't need to be in the data the user downloads, and that would be good to know.
From the wiki: https://github.com/rkulagowski/tv_grab_na_sd/wiki
Free-to-air satellite lineup
Because free-to-air has a number of parameters that don't map exactly into the cable and over-the-air format, it will look like this:
{"name":"Free-to-air satellite","location":"Global","satellites":[{"name":"AMC-1","location":"103.0 W"},{"name":"AMC-10","location":"135.0 W"}, ... {"name":"Simon Bolivar","location":"78.0 W"}]
The "satellites" object will be an array of name and location strings, indicating which satellites are described in the response.
"AMC-1":[{"frequency":3840000,"polarization":"h","symbolrate":26681000,"fec":"3\/4","videoPid":"0100","apidAnalog":"0101","stationID":18774},{"frequency":3840000,"polarization":"h","symbolrate":26681000,"fec":"3\/4","videoPid":"0200","apidAnalog":"0201","stationID":29117},{"frequency":3840000,"polarization":"h","symbolrate":26681000,"fec":"3\/4","videoPid":"0300","apidAnalog":"0301","stationID":21596}, ... ,{"frequency":4195000,"polarization":"v","symbolrate":2900000,"fec":"1\/2","videoPid":"1110","apidAnalog":"1211","apidDigital":"1212","stationID":15223}],"AMC-10":[{"frequency":3723000,"polarization":"h","symbolrate":1559000,"fec":"3\/4","videoPid":"0257","apidAnalog":"0258"},{"frequency":3820000,"polarization":"h","symbolrate":29270000,"fec":"3\/4","videoPid":"1260","apidDigital":"1220","stationID":14755},
Next will be a number of entries for each satellite, describing the services available on each.
After all of the satellite content on the transponders has been defined, the file will contain the stationID definitions:
"stationID":[{"name":"KUSMDT (KUSM-DT)","callsign":"KUSMDT","affiliate":"PBS Affiliate","broadcaster":{"city":"Bozeman","state":"MT","zipcode":"59717","country":"United States"},"stationID":43025},{"name":"KETADT (KETA-DT)","callsign":"KETADT","affiliate":"PBS Affiliate","broadcaster":{"city":"Oklahoma City","state":"OK","zipcode":"73111","country":"United States"},"stationID":43184}, ... {"name":"Abu Dhabi TV","callsign":"ABUDHAB","affiliate":"Satellite","broadcaster":{"city":"Abu Dhabi","state":"","zipcode":"00000","country":"United Arab Emi"},"stationID":49606}]
This will allow the client to correlate the transponder information with the name of the provider to determine what needs to be requested from the server.
The final part of the file will contain:
"metadata":[{"device":"FTA","modified":"2013-01-18T19:55:36Z"}]}
---------------
The user (or their application) would download the FTA file, parse the satellite names, (including some non-North Americas), determine which ones the user is interested in (with stationID as the key), and then request those stationID's. The stationID file has the next 2 weeks of scheduling information in it.
If you're familiar with our existing service offering, if you wanted schedule data for KETA you needed to add a lineup in OK, and to get KUSM you needed to add a lineup in Montana, to get LPB you'd need to add New Orleans, etc. You would quickly run out of lineups (since you're capped at 4), and there was no way of making a "custom" lineup. We're trying to make sure that we can provide something that encompasses the old 4DTV lineup, as well as providing data for Ku FTA.
If you've got some feedback on the format that I came up with, I'd love to hear about it.
Thanks.
We've (I've) been working on a lineup for Free-to-Air for our new JSON data service for scheduling. Since I don't have a FTA system, I've been trying to deduce what's important and what's not.
Since we're still in beta, I'm trying to ensure that our FTA lineup has the information that's actually required / useful, so we're soliciting feedback. If something like "FEC" or symbolrate isn't important to anyone, and no application or tuner actually uses it because it's all "auto", then it doesn't need to be in the data the user downloads, and that would be good to know.
From the wiki: https://github.com/rkulagowski/tv_grab_na_sd/wiki
Free-to-air satellite lineup
Because free-to-air has a number of parameters that don't map exactly into the cable and over-the-air format, it will look like this:
{"name":"Free-to-air satellite","location":"Global","satellites":[{"name":"AMC-1","location":"103.0 W"},{"name":"AMC-10","location":"135.0 W"}, ... {"name":"Simon Bolivar","location":"78.0 W"}]
The "satellites" object will be an array of name and location strings, indicating which satellites are described in the response.
"AMC-1":[{"frequency":3840000,"polarization":"h","symbolrate":26681000,"fec":"3\/4","videoPid":"0100","apidAnalog":"0101","stationID":18774},{"frequency":3840000,"polarization":"h","symbolrate":26681000,"fec":"3\/4","videoPid":"0200","apidAnalog":"0201","stationID":29117},{"frequency":3840000,"polarization":"h","symbolrate":26681000,"fec":"3\/4","videoPid":"0300","apidAnalog":"0301","stationID":21596}, ... ,{"frequency":4195000,"polarization":"v","symbolrate":2900000,"fec":"1\/2","videoPid":"1110","apidAnalog":"1211","apidDigital":"1212","stationID":15223}],"AMC-10":[{"frequency":3723000,"polarization":"h","symbolrate":1559000,"fec":"3\/4","videoPid":"0257","apidAnalog":"0258"},{"frequency":3820000,"polarization":"h","symbolrate":29270000,"fec":"3\/4","videoPid":"1260","apidDigital":"1220","stationID":14755},
Next will be a number of entries for each satellite, describing the services available on each.
- "frequency" - kHz.
- "polarization" - l, r, c, h, v. "left", "right", "circular", "horizontal", "vertical".
- "symbolrate"
- "fec" - Forward Error Correction.
- "videoPid"
- "apidAnalog" and "apidDigital".
- stationID
After all of the satellite content on the transponders has been defined, the file will contain the stationID definitions:
"stationID":[{"name":"KUSMDT (KUSM-DT)","callsign":"KUSMDT","affiliate":"PBS Affiliate","broadcaster":{"city":"Bozeman","state":"MT","zipcode":"59717","country":"United States"},"stationID":43025},{"name":"KETADT (KETA-DT)","callsign":"KETADT","affiliate":"PBS Affiliate","broadcaster":{"city":"Oklahoma City","state":"OK","zipcode":"73111","country":"United States"},"stationID":43184}, ... {"name":"Abu Dhabi TV","callsign":"ABUDHAB","affiliate":"Satellite","broadcaster":{"city":"Abu Dhabi","state":"","zipcode":"00000","country":"United Arab Emi"},"stationID":49606}]
This will allow the client to correlate the transponder information with the name of the provider to determine what needs to be requested from the server.
The final part of the file will contain:
"metadata":[{"device":"FTA","modified":"2013-01-18T19:55:36Z"}]}
---------------
The user (or their application) would download the FTA file, parse the satellite names, (including some non-North Americas), determine which ones the user is interested in (with stationID as the key), and then request those stationID's. The stationID file has the next 2 weeks of scheduling information in it.
If you're familiar with our existing service offering, if you wanted schedule data for KETA you needed to add a lineup in OK, and to get KUSM you needed to add a lineup in Montana, to get LPB you'd need to add New Orleans, etc. You would quickly run out of lineups (since you're capped at 4), and there was no way of making a "custom" lineup. We're trying to make sure that we can provide something that encompasses the old 4DTV lineup, as well as providing data for Ku FTA.
If you've got some feedback on the format that I came up with, I'd love to hear about it.
Thanks.