![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
So since there's a lot of really smart people on here that love a good diagnostic challenge. I'll share some of my work with you and let's see what different ideas we come up with. 
One of our family businesses is a Chevron branded fueling station. The point of sale system and fuel pumps for that site are made by a company called Wayne-Dresser out of Austin, TX. (They are one of the only 2 fuel pump manufacturers in the US, the other being Gilbarco.)
The Point of Sale system itself is a Fujitsu TeamPOS 3600. This is a Intel Core Duo LGA775-based system with 4 Dimm sockets and a bunch of custom stuff to make it a solid POS hardware platform like Intel RAID1, additional usb and serial ports, powered serial ports, and an Anatel pice modem. There is a second terminal that has similar specs, but no second drive in the RAID (and the motherboard may be different, but I can't confirm that). (For those wondering, the processor is an e7400 and top of the line in the service manual is an e8400.)
This system connects to a Wayne Fusion controller which basically interfaces between the POS and the fuel pumps themselves. The pumps are more computer than fuel pump--the entire pump section from about 2 feet off the ground is nothing but a computer that could be replaced with an ipad. (But of course people would freak out if there was only an ipad and a fueling nozzle so here we are, lol.)
Like anything software, there can be communication glitches and whatnot--especially with custom software that hasn't been tested by the masses like retail software. Wayne's 'Nucleus' Point of Sale software runs on Windows Embedded POSReady 2009, so basically XP. It interfaces to the Fusion which in turn interfaces with the pumps all via proprietary protocols and software that can mess up decently easily, but works for months without issue once it's working.
About a week ago, sometime in the dead of night an owl landed on a nearby pole transformer. One of our security cameras captured the resulting light from the fireball, and in the dark of the night it looked like the sun.
One explosion and then another with what looked like blue and purple smoke, and then all the lights went dark.
While our POS and Fusion are on UPSes, there's no way to put an entire fuel pump that requires its own 20amp breaker on one (at least not in our budget and not commonly in this industry). So the pumps shut off until power was restored. Now, remember these pumps are computers, so they have configuration data of all sorts that's needing to be stored, and their communication to the Fusion and Nucleus was abruptly cut off so it wasn't a 'neat' shutdown.
Well after the pumps are fired back up, pumps 3 & 4 are acting like they're not communicating at all. (Pumps 3&4 are actually two different 'sides' to a single physical pump.) But after working with Wayne's tech support, it could just be a stuck state at the pumps as they did respond to power cycles of all the equipment. This is a good thing since Wayne has a way to remote into the Fujitsu via that Anatel modem to fix such software glitches.
Except...that is seems in a previous thunderstorm event that took out the 12v power brick on the 8-port gigabit switch, it also somehow got the modem. (Not really even sure how it got the power brick as everything is on APC Smart-UPS upses, but I guess it happens.)
So Wayne can't dial in to fix the potentially stuck pump. Rats--expensive, time-consuming service call. Or maybe not...
There's an upgrade cycle in progress so a lot of these Fujitsu systems are hitting ebay hard--cheap spare parts! I picked up an entire spare for $50 just yesterday. And it has the same Anatel modem in it.
The Anatel modem is apparently a pci-e modem that is a softmodem, so not a complete hardware modem. So it will need software support to work and/or be tested.
So now comes the part I wanted to pick your brains on--how to test the Anatel modem in the unit I have for correct operation, and how to do the same testing on my production system to confirm the bad modem before swapping?
My thoughts have been this--use a linux live cd to boot and hopefully recognize the modem. If it's recognized, great! Find a phone line and get it to try to dial. If it tries to dial--good enough to say the modem is good.
Same test on the production system and if the modem isn't recognized (like it no longer was in the native POSready 2009), then the modem is definitely dead and swap it.
Now, there's 100 different ways to skin a cat, ie fix the pump issue, but keep in mind that's not my question--it's how to test the modem.
Love to hear some thoughts, and thank you in advance!
One of our family businesses is a Chevron branded fueling station. The point of sale system and fuel pumps for that site are made by a company called Wayne-Dresser out of Austin, TX. (They are one of the only 2 fuel pump manufacturers in the US, the other being Gilbarco.)
The Point of Sale system itself is a Fujitsu TeamPOS 3600. This is a Intel Core Duo LGA775-based system with 4 Dimm sockets and a bunch of custom stuff to make it a solid POS hardware platform like Intel RAID1, additional usb and serial ports, powered serial ports, and an Anatel pice modem. There is a second terminal that has similar specs, but no second drive in the RAID (and the motherboard may be different, but I can't confirm that). (For those wondering, the processor is an e7400 and top of the line in the service manual is an e8400.)
This system connects to a Wayne Fusion controller which basically interfaces between the POS and the fuel pumps themselves. The pumps are more computer than fuel pump--the entire pump section from about 2 feet off the ground is nothing but a computer that could be replaced with an ipad. (But of course people would freak out if there was only an ipad and a fueling nozzle so here we are, lol.)
Like anything software, there can be communication glitches and whatnot--especially with custom software that hasn't been tested by the masses like retail software. Wayne's 'Nucleus' Point of Sale software runs on Windows Embedded POSReady 2009, so basically XP. It interfaces to the Fusion which in turn interfaces with the pumps all via proprietary protocols and software that can mess up decently easily, but works for months without issue once it's working.
About a week ago, sometime in the dead of night an owl landed on a nearby pole transformer. One of our security cameras captured the resulting light from the fireball, and in the dark of the night it looked like the sun.
One explosion and then another with what looked like blue and purple smoke, and then all the lights went dark.While our POS and Fusion are on UPSes, there's no way to put an entire fuel pump that requires its own 20amp breaker on one (at least not in our budget and not commonly in this industry). So the pumps shut off until power was restored. Now, remember these pumps are computers, so they have configuration data of all sorts that's needing to be stored, and their communication to the Fusion and Nucleus was abruptly cut off so it wasn't a 'neat' shutdown.
Well after the pumps are fired back up, pumps 3 & 4 are acting like they're not communicating at all. (Pumps 3&4 are actually two different 'sides' to a single physical pump.) But after working with Wayne's tech support, it could just be a stuck state at the pumps as they did respond to power cycles of all the equipment. This is a good thing since Wayne has a way to remote into the Fujitsu via that Anatel modem to fix such software glitches.
Except...that is seems in a previous thunderstorm event that took out the 12v power brick on the 8-port gigabit switch, it also somehow got the modem. (Not really even sure how it got the power brick as everything is on APC Smart-UPS upses, but I guess it happens.)
So Wayne can't dial in to fix the potentially stuck pump. Rats--expensive, time-consuming service call. Or maybe not...
There's an upgrade cycle in progress so a lot of these Fujitsu systems are hitting ebay hard--cheap spare parts! I picked up an entire spare for $50 just yesterday. And it has the same Anatel modem in it.
The Anatel modem is apparently a pci-e modem that is a softmodem, so not a complete hardware modem. So it will need software support to work and/or be tested.
So now comes the part I wanted to pick your brains on--how to test the Anatel modem in the unit I have for correct operation, and how to do the same testing on my production system to confirm the bad modem before swapping?
My thoughts have been this--use a linux live cd to boot and hopefully recognize the modem. If it's recognized, great! Find a phone line and get it to try to dial. If it tries to dial--good enough to say the modem is good.
Same test on the production system and if the modem isn't recognized (like it no longer was in the native POSready 2009), then the modem is definitely dead and swap it.
Now, there's 100 different ways to skin a cat, ie fix the pump issue, but keep in mind that's not my question--it's how to test the modem.
Love to hear some thoughts, and thank you in advance!
