@Jase88 is there a way, you can ask your contact, if they can add EPG on for 69.1 20.1 and 31.1 both have it. It would be nice to have

I have recently disconnected my TO antenna and just use a 4221HD stacked for BUF (aimed ESE). Even though the stack is aimed 90 degrees away from the CN tower, all the TO stations come in very strong, even VHF 9 - CFTO; the exception being OMNI 2 on 69 (RF 51)- it still comes in solidly just lower strength than OMNI 1/CITY which are almost identical in strength. Dropping the ganged set-up allows the weakest BUF to come in, i.e., WNYO.

Thanks for the update Jase. I've seen an improvement on Omni1 and City during the last week, but I was hoping the signal strength would be stronger :). I can receive the stations more often than before, but not all the time.

OTA-London, I attempted several weeks ago to determine if this was still an issue. But apparently few OTA'ers in London use an EPG...or my post got missed.

I'll certainly ask again and post an update.

Just to confirm: It's OMNI2 (virtual 69.1) that's missing PSIP data?! Does anything show (i.e. "DTV Program"), or is it just blank?!

Either way, I've left my contact a voicemail, and will hopefully hear back soon.

Its OMNI 1 -69.1 or rf of 48

OMNI 2 20.1 has EPG, and City TV has it to. When we watch it on 69.1 it says no program information

...But apparently few OTA'ers in London use an EPG...

Yeah, I just use schedulesdirect.org for my myth backend and otherwise, it is useless. My TV has no guide; it just shows the title of what you are already watching.

I've been waiting on 69.1 epg as well on rf 48. Seemed odd to me that 31.1 and 20.1 both have epg but not 69.1.

Indeed it's odd--EPG works on all of the Rogers Toronto stations. Must be a technical oversight of some sort...

Hi All,

Anyone know if OMNI 2 signal strength in Toronto will be bumped up after the new year? Based on CRTC's website, it indicate that CityTV, OMNI 1 and 2 is transmitting at lower strength until Dec. 31, 2011. City and OMNI 1 is registering at close to 100%, but OMNI 2 is only at 55%. It used to be around 30% for OMNI 2. Curious if anyone saw a strength increase after the new year. Thanks.

There has been no change to OMNI2 Toronto's ERP. The station continues to broadcast from First Canada Place in Toronto. There is a pending application for this station to move from channel 51 (it's current allocation) to channel 40. Once approved, the transmitter will also relocate to the CN Tower, where it's height will increase by over 100m from it's current HAAT. That height will likely result in far better reception (as it did with OMNI1 and CITY TV).

I totally agree with scoltx,
OMNI1 out of London on RF48 (69.1) is indeed missing it's PSIP. But, OMNI2 (20.1) and Citytv (31.1) both have PSIP.
Seems strange - maybe Rogers will look at correcting it?
Hopefully Jase88 will get a response/ETA from his Rogers contact.

Called my contact today...he doesn't have an update, but promises one soon. They're equally confused, as the data is being carried by common elements to both transmitters in London (OMNI 1 and 2).

Its too bad they don't have a reliable way to contact engineering people more directly ... we could have sorted this months ago. Anyway, thanks for passing it on, Jase.

Communication is not the issue here. At least not internally. Obviously it's difficult for viewers to reach the right department.

I suspect the delay is one of priority: They likely don't have personnel based out of the London area. Therefore a technician would need to travel to London, likely staying the night should any work necessitate taking the signal offline. Lots of money to just restore EPG data.

They'll probably wait until a regular or scheduled visit is necessary.

But a large company that owns its own fibre backbone should have a way to backhaul an OTA signal monitor stream to Toronto so they could decode their own data stream remotely. The site visit is only to debug why it is wrong, not that the broadcast data stream is wrong.

Good point, tvlurker. And I'm sure Rogers has those facilities/tools. It might just be a case of getting someone to sit down and troubleshoot it.

Same way I'm sure they've yet to tackle the GPS time offset problem. (ATSC system time on their Ottawa channels is consistently 15 seconds slow. This is likely to be due to setting the GPS offset in the data stream to zero instead of 15).

Global Ottawa suffers from the same issue, but CTV and CTV2 are OK. (No one else in Ottawa except TVO is bothering to send the correct time at all.)

tvlurker, I just checked the Toronto stations' STT tables via TSReader and found something that may interest you. GPS/UTS offset is set to 15 (correct value) and the resulting time is exactly 15 seconds slow. It looks like it is being doubly accounted for.

system_time is supposed to be unadjusted (that is, including leap seconds) while GPS_UTC_offset is used to adjust to actual time. So system_time is 15 seconds slow.

El Gran Chico, thanks for checking what the GPSOffset is set to in the STT.

I'm not sure what you meant by "system_time is supposed to be unadjusted (that is, including leap seconds)"

According to the ATSC spec, system time is straight GPS time, which does not include leap seconds, which means it will always appear to be GPS-Offset seconds faster than current UTC time.

The tuner is supposed to subtract GPSoffset from the system time in order to display local UTC-based time (adjusted for the timezone).

So if the tuner is displaying a time which is 15 seconds slow, and as you say the GPSOffset is set correctly in the STT table, then the system time must have been set to UTC, not GPS time which is UTC+GPSOffset.

system_time — A 32-bit unsigned integer quantity representing the current system time as the number of GPS seconds since 00:00:00 UTC, 6 January 1980. The count of GPS seconds and leap second count shall be accurate and correct to within plus or minus one second, for a direct main broadcast signal RF receiving device, as timed at the arrival in the decoder of the Transport Stream packet carrying the last byte of the CRC. The STT seconds count should be set to the next second and sent approximately 2T milliseconds before the seconds count is due to increment, where T represents the average number of milliseconds between TS packets identified with the SI base_PID (0x1FFB). If one or more translators and/or repeaters are in the RF delivery path that introduce processing delays that impact the overall STT timing accuracy, the STT timing should be adjusted in the translated/repeated signal.

Tvlurker, sorry if I wasn't clear (complicated to put in so many words :o) but I agree with what you say in your post following it.