I'm installing a new three site VHF simulcast system tied together with Canopy PTP-600 4.9Ghz product. None of the sites have LOS. So, there is a fourth site used just for linking the tower sites back to the prime. That requires synchronizing the PTP links to prevent self interference. However, the link timing values produced by Link Planner are not working, and none of the links will acquire. Bypassing the sync units and disabling TDD allows the links to acquire proving the path calcs and dish alignments are correct. Has anyone successfully deployed Canopy PTP-sync? Supposedly it is as easy as falling off a rock.
http://www.youtube.com/watch?v=YyLjaCmTAg8
Any experience with Canopy PTP-sync?
Moderator: Queue Moderator
Re: Any experience with Canopy PTP-sync?
I revisited the problem, re-entered the sync calc values, and this time all the links came up. Darned if I know what happened. It does take longer to acquire than normal by about twenty seconds - from ninety sec to almost two min - but the solution does work. It restores the rsl's to the correct levels and cuts the errors.
BTW - Harris Synchro-Cast rocks!
BTW - Harris Synchro-Cast rocks!
Re: Any experience with Canopy PTP-sync?
You can always call Jim Hong directly. I've been to several of his training sessions and he is very friendly and knowledgeable and has always been happy to help.
Re: Any experience with Canopy PTP-sync?
Good to know. Thanks.
Re: Any experience with Canopy PTP-sync?
Let me know if you need his contact information, I can send it to you via PM. All of my experiences with Jim were positive ones, he took extra time out of his day to help me troubleshoot a few issues I was having with a system once our training class was over.
Re: Any experience with Canopy PTP-sync?
Training? What mean this strange word training? Speaking in riddles, this one, you are. Real men rtfm! 
Re: Any experience with Canopy PTP-sync?
Discovered something new about PTP-Sync today - (a) the sync box can be broken but still give you perfectly normal front panel indications, and (b) set your longest link as the cluster master, not your shortest. Neither are discussed in the user guide, or Link Planner. I determined the first by substitution, and the second by dinking. After several frustrating months of intermittent link failures chasing apparent interference along with atmospherics, out of desperation I turned off the sync, and bingo. A lot of problems disappeared leaving just the nightly atmospherics. I was very tempted to leave PTP-sync off, but one link was taking some hits, and it used to be the well behaved one suggesting sync worked for it.
Ordered a replacement sync module and spent part of a day swapping it into place and waiting because the problem didn't always manifest itself right away. Once I was happy I had determined the less-than-perfect sync unit, I went through the trouble of mounting it, and let 'er rip. We could never go more than 24hrs without a link failure, and now the system made it through a week with just atmospheric fades around midnight. But, the performance still wasn't right. Sync turned on or off, the rsl would remain constant, but the vector errors were like a roller coaster. Throughput would drop, but never fail, and over time you could see a pattern emerge.
The link back to the prime site was the designated cluster master. It is also the shortest hop. I rearranged the cableing, and reconfigured the longest hop as the cluster manager. Magic! Vector errors flattened right out. Throughput stayed constant. If it runs for a week without the roller coaster, then I can go after the fading with diversity. One thing at a time.
Ordered a replacement sync module and spent part of a day swapping it into place and waiting because the problem didn't always manifest itself right away. Once I was happy I had determined the less-than-perfect sync unit, I went through the trouble of mounting it, and let 'er rip. We could never go more than 24hrs without a link failure, and now the system made it through a week with just atmospheric fades around midnight. But, the performance still wasn't right. Sync turned on or off, the rsl would remain constant, but the vector errors were like a roller coaster. Throughput would drop, but never fail, and over time you could see a pattern emerge.
The link back to the prime site was the designated cluster master. It is also the shortest hop. I rearranged the cableing, and reconfigured the longest hop as the cluster manager. Magic! Vector errors flattened right out. Throughput stayed constant. If it runs for a week without the roller coaster, then I can go after the fading with diversity. One thing at a time.
Re: Any experience with Canopy PTP-sync?
Excellent informative post. You may save someone a lot of work in the future!
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: Any experience with Canopy PTP-sync?
Oh come on. We live for these moments of frustration. We like milking the hard problems until our customers are ready to scream. It's what we do.
Re: Any experience with Canopy PTP-sync?
Update on this system - while we waited for the new dish to arrive so we could implement diversity, the link that used to bounce the hardest from atmospherics bounced real hard last weekend. It was an all night event which gave me time to dink with it remotely during the failure. I discovered I could make the link more robust by doing two things - turn on dual payload, and manually turning down the max rx mod mode.
In the manual is a discussion about dual payload and single payload. In dual payload, the two beams can send different ethernet streams essentially doubling the throughput of the link. In single payload, it sends the same ethernet stream on the two beams. It also mentions you can make a link more robust by disabling dual payload. By toggling dual payload, I could watch the link improve with dual on, or deteriorate with dual off. The same atmospheric was affecting the other links as well, but they were surviving. Enabling dual mode in them improved their vector errors making the event less apparent.
The other subtle improvement came by turning down the maximum receive adaptive modulation mode from the maximum 256QAM with .81 error correction to 16QAM .87ec. There isn't any in depth discussion about the adaptive rate except that you can set it. I experimented by ticking the rate down one step at a time and watching the vector errors. 16QAM .87 seemed to give me good ethernet throughput (about 11mbps, down from 22mbps) with much increased stability. It was the fastest rate I could run without the link bouncing during the atmospheric event. Just like dual payload, adjusting the value on the other links improved their vector errors. Since they were already surviving the event, I left them at max. But, if they ever experience a similar problem, I know what to try.
The dish came in this week from Hutton. We installed it on our problem child, but I left my previous settings alone. It went five days without a problem with the new settings which is promising. We have had hot afternoons followed by quick evening cool off which generally sparks an inversion. However, there was no dusk or dawn event showing up on the vector error graph after the diversity antenna went in. I guess we'll just see how it goes.
In the manual is a discussion about dual payload and single payload. In dual payload, the two beams can send different ethernet streams essentially doubling the throughput of the link. In single payload, it sends the same ethernet stream on the two beams. It also mentions you can make a link more robust by disabling dual payload. By toggling dual payload, I could watch the link improve with dual on, or deteriorate with dual off. The same atmospheric was affecting the other links as well, but they were surviving. Enabling dual mode in them improved their vector errors making the event less apparent.
The other subtle improvement came by turning down the maximum receive adaptive modulation mode from the maximum 256QAM with .81 error correction to 16QAM .87ec. There isn't any in depth discussion about the adaptive rate except that you can set it. I experimented by ticking the rate down one step at a time and watching the vector errors. 16QAM .87 seemed to give me good ethernet throughput (about 11mbps, down from 22mbps) with much increased stability. It was the fastest rate I could run without the link bouncing during the atmospheric event. Just like dual payload, adjusting the value on the other links improved their vector errors. Since they were already surviving the event, I left them at max. But, if they ever experience a similar problem, I know what to try.
The dish came in this week from Hutton. We installed it on our problem child, but I left my previous settings alone. It went five days without a problem with the new settings which is promising. We have had hot afternoons followed by quick evening cool off which generally sparks an inversion. However, there was no dusk or dawn event showing up on the vector error graph after the diversity antenna went in. I guess we'll just see how it goes.
Re: Any experience with Canopy PTP-sync?
This is what a bad vertical connector on the PTP49600 *and* a bad horizontal connector on the dual polar dish looks like in the vector error and V/H ratio screen. It is not caused by the jumpers. Replacing the jumpers did not fix this. We think one of the original jumper cables had a bent NM center pin that spread the contacts of the NF as it was inserted. The crew couldn't get it to mate properly. So they tried it in another connector. No luck there. So, they swapped out the jumper and buttoned it up. We swapped out jumpers once before which seemed to fix it for a bit, but it came back with a vengence over a week later. Roughly wiggling the connectors did not get them to fail during reinspection. It took a light touch in the right direction to get the center to open causing the vectors errors to maximize, and the link to fail. A real bugger to find.
Re: Any experience with Canopy PTP-sync?
One week later, and zero errors on this link after replacing the jumpers for the second time. Hard lessons learned on this one. I've had N connectors give me grief before if the center pin is inset by a hair. If the mating side is also inset, then the perfect opportunity for intermittent operation exists, and it can drive you nuts. If this were all indoors on a combiner with transmitters throwing intermittent vswr alarms, I would have found it quickly I hope. I've had it happen. But, with Canopy PTP product, everything is up the tower at the dish. I don't get to casually wiggle and giggle and take things apart to look inside.
We've all had at least one high vswr problem that fixed itself as soon as you put your wattmeter in line. This stand out pretty fast. I remember a DB25 serial connector dogging me to death one time that turned out to be the male pins were too narrow by an angstrom. If I inserted my breakout box, all the clocking errors disappeared. There was nothing to measure or diagnose. But, within minutes of restoring the cables, I'd get near end and far end rx clock errors which caused framing errors. It took a while for it to dawn on me that the installed cable had the cheap rolled gold pins, and my breakout box had the machined pins. Swapped out the cable with a better quality, and bingo - problem solved.
I'm thinking the same thing happened with our bad PTP link - that we ran into a parts tolerance problem between the LMR400 jumper center pins into the mating side versus the slightly larger diameter half inch superflex center pins which we ended up using on this particular end. The other links are using the same LMR materials without failure. Without dropping the dish and radio to the ground to look inside all the female connectors, I have to depend on the experience of the crew when they say the center pins look good up there.
We've all had at least one high vswr problem that fixed itself as soon as you put your wattmeter in line. This stand out pretty fast. I remember a DB25 serial connector dogging me to death one time that turned out to be the male pins were too narrow by an angstrom. If I inserted my breakout box, all the clocking errors disappeared. There was nothing to measure or diagnose. But, within minutes of restoring the cables, I'd get near end and far end rx clock errors which caused framing errors. It took a while for it to dawn on me that the installed cable had the cheap rolled gold pins, and my breakout box had the machined pins. Swapped out the cable with a better quality, and bingo - problem solved.
I'm thinking the same thing happened with our bad PTP link - that we ran into a parts tolerance problem between the LMR400 jumper center pins into the mating side versus the slightly larger diameter half inch superflex center pins which we ended up using on this particular end. The other links are using the same LMR materials without failure. Without dropping the dish and radio to the ground to look inside all the female connectors, I have to depend on the experience of the crew when they say the center pins look good up there.
Re: Any experience with Canopy PTP-sync?
Thanks for posting all the excellent information Bill. It reminds us that often times, problems do indeed stem from the simplest of things.
One thing I'm not clear on...did all the issues in this thread happen due to the jumpers, or were there indeed issues with atmospherics requiring diversity receivers & adjustment of the adaptive modulation & dual payload? Just curious, as we've installed a PTP300 link (with no issues, thankfully) and will likely do more in the future.
Todd
One thing I'm not clear on...did all the issues in this thread happen due to the jumpers, or were there indeed issues with atmospherics requiring diversity receivers & adjustment of the adaptive modulation & dual payload? Just curious, as we've installed a PTP300 link (with no issues, thankfully) and will likely do more in the future.
Todd
No trees were harmed in the posting of this message...however an extraordinarily large number of electrons were horribly inconvenienced.
Welcome to the /\/\achine.
Welcome to the /\/\achine.
Re: Any experience with Canopy PTP-sync?
Todd - At this point, I'd have to say honestly I don't know. This is the 15th or 20th PTP link I've deployed, but it has been the hardest to make work. Normally, they come out of the box ready to run. It is the first one with PTP-sync. It did not work without starting over. All the links were stuck in acquiring until we re-entered the values. But, did parts tolerances on center pins mating bite us in the butt on everything else? Maybe. I know that I learned a lot about reading the tea leaves in PTP diagnostics, and how to make a link in failure more tolerant of the failure. This was a gotcha.
Re: Any experience with Canopy PTP-sync?
I wonder if someone got a 75-ohm N mixed in there somewhere. 75-ohm Ns have a smaller center pin and can lead to all sorts of difficult-to-diagnose problems.
Re: Any experience with Canopy PTP-sync?
Great thought, but no. The 75 ohm are needle thin. It wouldn't, or shouldn't, have fit the center conductor.
Re: Any experience with Canopy PTP-sync?
Update on problem - another week of perfect operation since we swapped out LMR400 jumpers with half inch superflex. I've experimented with both types at the shop and it is not LMR versus superflex causing the problem - it is the connectors.
The RF Industries LMR connectors from Tessco have very steep tapers on the center pins while the Andrews superflex have straight pins with blunt ends. There is more mating surface and more pin width in the first millimeter on the superflex center pins than the LMR. This is a problem for the LMR connectors if you do a perfect job of assembly because only the tapered portion of the pin mates with the receptacle on the female side. There is very little contact tension. Any flexing in the cable will cause the pin to move perfectly center and lose all contact. If you assemble it with the pin slightly extended beyond the headshell, or if you skew the pin from center, you'll get better contact tension, and no intermittent opens. Superflex connectors don't have this problem since they are wider at the tip with better tension if you get the center pin flush with the headshell. If it is inset by a millimeter, then you will have the same problem.
I pointed this out to Canopy support. In their defense, they purchase chassis mount female connectors just like every other OEM in the world. If there is a problem, it's with the supplier. N connectors have been around for a long time. But, if you look carefully, you can see differences in the center pins among the manufacturers. I looked through my adapters, and was amazed. Some adapter center pins were inset almost a millimeter. Others were flush but had a steep taper. Other were flush with a blunt tip. I could recreate the vector errors on the bench with most of my adapters except the blunt tipped ones with older PTP product. So, this isn't a new problem.
It makes me wonder how many jumpers I've made through the years for combiners and stations that might have intermittent operation under the right conditions. Oy vey.
The RF Industries LMR connectors from Tessco have very steep tapers on the center pins while the Andrews superflex have straight pins with blunt ends. There is more mating surface and more pin width in the first millimeter on the superflex center pins than the LMR. This is a problem for the LMR connectors if you do a perfect job of assembly because only the tapered portion of the pin mates with the receptacle on the female side. There is very little contact tension. Any flexing in the cable will cause the pin to move perfectly center and lose all contact. If you assemble it with the pin slightly extended beyond the headshell, or if you skew the pin from center, you'll get better contact tension, and no intermittent opens. Superflex connectors don't have this problem since they are wider at the tip with better tension if you get the center pin flush with the headshell. If it is inset by a millimeter, then you will have the same problem.
I pointed this out to Canopy support. In their defense, they purchase chassis mount female connectors just like every other OEM in the world. If there is a problem, it's with the supplier. N connectors have been around for a long time. But, if you look carefully, you can see differences in the center pins among the manufacturers. I looked through my adapters, and was amazed. Some adapter center pins were inset almost a millimeter. Others were flush but had a steep taper. Other were flush with a blunt tip. I could recreate the vector errors on the bench with most of my adapters except the blunt tipped ones with older PTP product. So, this isn't a new problem.
It makes me wonder how many jumpers I've made through the years for combiners and stations that might have intermittent operation under the right conditions. Oy vey.
Re: Any experience with Canopy PTP-sync?
RF Industries for site installations? You are a brave man. They can't even make spec on a PL259.
They do make great mini-UHFs though.
Thread has been a great read.
They do make great mini-UHFs though.
Thread has been a great read.
Re: Any experience with Canopy PTP-sync?
I hear ya. But, the 14515 RFI NM crimp/solder LMR connector is what is stocked. This lil incident has caused mgmt to revisit parts inventory preferences. Looking at other projects that went well in the past shows half inch superflex or clamp on LMR pre-made jumpers were ordered rather than site built LMR jumpers using the 14515. Connectorization issues may account for the mixed luck some people have had with LMR in general. Expensive lesson to learn fer sure. It was amazing the fubar they created.