PROBLEMS with DC switches at or near FM tower locations

[midsizewisp]

Any update to the reboots on FM towers? Should we just swap it with another switch? If so, what is recommended?

[sirhc]

Any update to the reboots on FM towers? Should we just swap it with another switch? If so, what is recommended?

Please read this post 2 pages up in this thread: viewtopic.php?f=17&t=1342&start=10#p10437

An inline filter will not fix this, we tried.

We are adding filters to the power supply and switch board.

I am sorry for this unforeseen issue but we are working to resolve it as fast as we can but this is not something that will be solved in a week or 2 by slapping a few components on a PCB as it will take weeks to order in experimental PCB's then to have them assembled then test them.

Part of the solution will be re-routing traces on the board on different PCB layers to provide better shielding, possibly changing the location on the board we pull I2C from, and finally adding filters to some circuits.

To get a little technical normal I2C communication has filtering mechanisms built in but the way we are achieving I2C is a process referred to as bit banging with GPIO pins which is perfectly acceptable in this application and widely used but sadly this method does not have these filter mechinisums built in.

This is also an extremely expensive process to fix this for just a few people having an issue when installing these DC switches on FM broadcast tower sites but none the less we are going to resolve it. This more than likely will cost us "many" thousands of dollars and increase our cost to produce these units in the future so that they will work in these difficult FM environments which we will have to absorb as we already have MSRP established and we will not raise the price.

The best suggestion I can give you at this time is use our AC powered models until we work this out as they do not appear to have this issue.

Our goal is to find a solution and modify the design and have it tested before we order the next production batch which has to be placed within 2-3 weeks as it is a 6-8+ weeks lead time from the time we place an order until we receive products or we will run out of stock (which we do not want to have happen) so you can see we are very much trying to speed this process along as fast as we can but this is not so simple or inexpensive.

You have to remember the idea behind making our DC switches (WS-8-250-DC, WS-12-DC, and WS-12-250-DC) was for OFF-GRID installations where WISPs have a small tower on a hill with a couple solar panels and a battery bank and no AC grid.

We were NOT thinking people would put these in boxes 300 feet in the air on FM tower towers or even near FM tower sites because normally if you are at an FM tower site they have generators for backup and you would be using our AC models.

So please have a little understanding that just because some people decided this would work as a TOWER Switch (which we are working on a TOWER Switch which does not have this issue with FM) have a little understanding that we did not foresee this nor did we test for this type of environment.

But with that said we are going to resolve this but it will not be fixed with firmware nor will it be fixed in a couple weeks, very sorry but physics is physics.

[wispwest]

Any idea what to do for my issue? I thought I saw something eluding to installing the 802.3af adapters.

If you are referring to Ethernet communications on FM towers this has been an issue with WISPs for many years.

The normal battle plan was has been using better shielded cables and in some cases putting the cable in metal conduits.

This issue has nothing to do with the switch design nor is it related to the I2C issue on our DC models with FM towers....well it is related in the sense that FM uses 80 to 108 Mhz and Ethernet uses the 100BaseT/Cat 5 clock rate of 125 MHz rate, but since more data is transmitted at the same time, the transfer rate is higher. The math is quite simple: 125 MHz x 2 bits per signal (i.e., per wire pair) x 4 signals per time = 1.000 Mbps.

And since FM is transmitted at a very HIGH EIRP to carry NLOS great distances the side band splash at these sites wipes out the Ethernet modulation and often forces errors and causes it to step down or not work at all.

fm.gif

Yes, finally an answer as to WHY we're always having these issues!!! Great explanation Chris! :)

[kbloch]

Just so you know we are not putting these boxes on the tower itself but in the building near the bottom of the tower. The RF signal is still strong enough adjacent to the tower that the switch still has issues. There are at least five FM radio stations with TX power exceeding 1000 Watts and several that are over 5000 watts at this site.

[sirhc]

Yea, the DC switches (Current versions) will not work at an FM site, either on the tower or in the shelter.

We are working on modifications to solve this and they will be implemented in future production batches.

We also have a new smaller model coming out in a couple months that should be fine with FM sites.

We are also working on improving the durability of the current sensors in future models. Current sensors can be blown if exposed to voltages greater than 80V (positive or negative). The most common reason for this is not properly bonding tower grounding systems to tower grounding systems and dedicated ground runs to radios/antennas.

Read these posts:
viewtopic.php?f=30&t=1429
viewtopic.php?f=30&t=188

Now blown current sensors are repairable but not covered under warranty because they are the result of poor grounding practices but we are working to make the switches as bullet proof as possible. We are also working on a way that the switch will constantly monitor the ground potential difference between your cabinet/hut and your radio/tower and alert you to the need to do better grounding. But these are next generation features.

[wisp-wand]

I still have issues with my WS-12-250DC switch and its not on a FM site, in fact I am the only tenant and its a roof.
Switch has crashed again, as below, upgrading tonight to 1.3.9 FINAL to see if that improves stability.

Jan 1 00:00:08 kernel: vtss_port: Loaded port module on board Luton26, type 5
Jan 1 00:00:09 system: Setting MAC address from flash configuration: EC:13:B2:XX:XX:XX
Jan 1 00:00:11 system: starting ntpclient
Jan 1 00:00:11 admin: adding lan (eth0.770) to firewall zone lan
Jan 1 00:00:12 admin: Unable to query power supply
Jan 1 00:00:21 dropbear[769]: Running in background
Jan 1 00:00:24 mini_snmpd[792]: started, listening on port 161/udp and 161/tcp
Jan 1 00:00:25 system: starting ntpclient
Jan 27 15:34:47 switch[784]: Error reading temp sensor
Jan 27 15:34:49 switch[837]: Detected cold boot
Jan 27 15:34:50 switch[837]: PoE enabled on port 2, PoE Smart is starting cable check
Jan 27 15:34:50 switch[837]: PoE enabled on port 3, PoE Smart is starting cable check
Jan 27 15:34:55 switch[837]: Port 2 cable check results: Open, Open, Open, Open
Jan 27 15:34:55 switch[837]: Port 2 passed PoE Smart cable check, turning on power
Jan 27 15:34:55 switch[837]: Port 3 cable check results: Open, Open, Open, Open
Jan 27 15:34:55 switch[837]: Port 3 passed PoE Smart cable check, turning on power

[sirhc]

I still have issues with my WS-12-250DC switch and its not on a FM site, in fact I am the only tenant and its a roof.
Switch has crashed again, as below, upgrading tonight to 1.3.9 FINAL to see if that improves stability.

Jan 1 00:00:08 kernel: vtss_port: Loaded port module on board Luton26, type 5
Jan 1 00:00:09 system: Setting MAC address from flash configuration: EC:13:B2:XX:XX:XX
Jan 1 00:00:11 system: starting ntpclient
Jan 1 00:00:11 admin: adding lan (eth0.770) to firewall zone lan
Jan 1 00:00:12 admin: Unable to query power supply
Jan 1 00:00:21 dropbear[769]: Running in background
Jan 1 00:00:24 mini_snmpd[792]: started, listening on port 161/udp and 161/tcp
Jan 1 00:00:25 system: starting ntpclient
Jan 27 15:34:47 switch[784]: Error reading temp sensor
Jan 27 15:34:49 switch[837]: Detected cold boot
Jan 27 15:34:50 switch[837]: PoE enabled on port 2, PoE Smart is starting cable check
Jan 27 15:34:50 switch[837]: PoE enabled on port 3, PoE Smart is starting cable check
Jan 27 15:34:55 switch[837]: Port 2 cable check results: Open, Open, Open, Open
Jan 27 15:34:55 switch[837]: Port 2 passed PoE Smart cable check, turning on power
Jan 27 15:34:55 switch[837]: Port 3 cable check results: Open, Open, Open, Open
Jan 27 15:34:55 switch[837]: Port 3 passed PoE Smart cable check, turning on power

It might help to provide information other than "this is what happens".

What firmware version were you using?
What are you powering it with?
What are you powering?

Also could you post up screen grabs of your Config Tabs mainly Status, Ports, Power, Device/Configuration, and Device/Status.

Can not help much without more information but YES please upgrade your firmware, always upgrade firmware to what ever is the latest version when you experience a problem then if the problem persists then make a detailed as possible post describing the problem and environment.

[lligetfa]

Jan 1 00:00:12 admin: Unable to query power supply
...
Jan 27 15:34:47 switch[784]: Error reading temp sensor

I wonder if this could be i2c issues? Do you have any SFP plugged into the switch?

[sirhc]

Jan 1 00:00:12 admin: Unable to query power supply
...
Jan 27 15:34:47 switch[784]: Error reading temp sensor

I wonder if this could be i2c issues? Do you have any SFP plugged into the switch?

Not sure, more concerned that he was running the firmware that came with it and prior to v1.3.8 there were major issues.

Then some issues were fixed in v1.3.9 so first things first, I hope he upgrades, then "if" the problem persists he will post more information that will help point us in some direction.

[wisp-wand]

What firmware version were you using?
1.3.8
What are you powering it with?
A Dycon 2403 switch-mode power supply charger at 24vdc which has 2 12v 7ah batteries. This PSU model powers most of my sites.
What are you powering?
1 x PBE-400 and a Rocket AC Lite
Do you have any SFP plugged into the switch?

Not using SFP

Here are the tabs

device status

As you can see its a simple setup. The switch uplink is from a CCR connected to port 4 which has a fibre backhaul connected.
The PBE-400 is connected to another tower. The CCR runs OSPF and prefers the fibre, but fails over to the PBE-400 is fibre fails.
Customers are connected to the rocket on port 3, PPPOE which is converted to EOIP and run over the OSPF network.
Let me know if you think any config needs changing the switch actually works fine apart from the crashing.