Just an update after long long silence. I am now trying to befriend Parallax Propeller with PAN1320 Bluetooth module.
Starting point http://svn.navi.cx/misc/trunk/propeller/usb-host/ (thanks Micah Elizabeth Scott) and Bluetooth specification.
One thing I do not understand about BT modules, why are all module manufacturers so secretive and require NDA to be signed to give you user manuals/datasheets? Really, wtf?
I happen to own Bosch dishwasher and one day it started to act up on me. It started to fill/drain continuously. The problem was infamous “impeller jug” http://www.espares.co.uk/part/dishwashers/bosch/sgs53c02gb%2f15/p/1083/856/0/998660/754220/dishwasher-impeller-jug.html, device that measures amount of water that is let into machine. This device consists of impeller that has magnet attached to it and reed switch that is switched on and off by the magnet attached to the impeller. Reed switches sometimes get stuck and that is exactly what happened to mine. Temporary fix is to pull out board with reed switch from jug casing and give it a few taps, as well you can do a few passes over strong magnet. Semi-permanent fix is to replace reed switch (it will get stuck eventually again, thus semi-permanent) with one like this http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1079468 and avoid spending 20 GBP or equivalent of your local currency on unnecessary plastic.
My mother-in-law happens to own Opel (or Vauxall in some countries where they drive on wrong side) Zafira A with Y22DTR diesel engine. Fuel pump in that engine is Bosch VP44 with PSG-16 management unit. For one reason or another Bosch has decided not to sell any spares for this specific version of pump. At the same time, there is single part that is prone to fail in these pumps and that part is hall sensor that measures pump shaft rotation (if you try to read ECU fault codes it is called “camshaft” sensor, but actually it is housed in pump itself). And of course this sensor failed.
So I searched around just to find that nobody would replace sensor alone, only whole pump assembly, which means ~2000 Euros around here. Neither did I accept the fact that I have to pay 2000 Euros for a repair of part that costs less that 10, nor did I have spare pile of Euros to throw in the car that by now has a value of around 4000 Eur.
First I tried to use some off the shelf hall sensor bought from Farnell, it was a bit too high (or thick depending on how you look at it) and was getting in a way of sensor wheel teeth. Next I found that the same sensor from different model of the same pump – VP44/PSG-5, looks the same and can actually be bought as a spare. The only obvious difference between PSG-5 and PSG-16 sensors is flat cable assembly that is integral part of sensor.
Next step was to source used, but known good sensor from PSG-5 and try to figure how to implant that into PSG-16. Solution was apparent because part of cable going into the sensor is of the same width on both sensors and seemed to have the same trace layout. So both cable assemblies were cut in a place where width matches, leaving a little bit longer cable ends to make them overlap and at the same time provide for necessary total length. Then plastic, that makes up cable body, was scraped off of one side of cable going to management unit revealing clean copper traces. Thin layer of solder was applied to those traces (I used desoldering wick to remove excess solder) and the same was repeated with the opposite side of cable coming from sensor. At this point I should have used some fuel resistant heatshrink tubing (like Tyco/Raychem DR-25) to make it sturdier, but I did not have it at hand. So I just went ahead and pressed both cable ends together and heated them with soldering iron. That provided for good enough electrical connection. Then some superglue was applied to the joint to make it stronger physically and sensor was soldered back to pump management unit.
Next day revealed that both sensors are indeed the same and after removing air from fuel lines engine happily started again.
1950 Euros saved and Bosch vs hackers – 0:1.
Please read iFixit Self-Repair Manifesto.
I can totally sign under each and every word in this Manifesto.
As weird as it sounds, it is exactly that, ethernet bridge over 3G/GPRS. If you want to make your own, you will need: two machines running Linux, each with one ethernet interface and one 3G/GPRS interface, OpenVPN and a little of configuration.
First, create tap interfaces on each end (check OpenVPN docs on how to do that)…
Then bridge those with ethernet interfaces…
Now bring up your 3G (in fact, it is even easier if you have fixed connection on one end as OpenVPN server needs fixed IP)…
Next, configure OpenVPN over your tap interfaces without IP addresses and/or routing…
Start OpenVPN and see how everything coming in on ethernet interface of one of your linux boxes is going out on another and vice versa.
As for me, I used two Teltonika RUT-104 devices, slightly improved OpenWRT and SIM with fixed IP on one end. Of course, if you can not get SIM with static public IP, you can use DDNS and dynamic IP, but it still has to be public and of course, as mentioned above, server end of business does not have to be on 3G at all, it can be anywhere on internets and even behind NAT, as long as you can forward OpenVPN traffic to it.
This is small FreePBX module that let agents see who is logged on, log on, log off, see last ten calls and listen to their recordings.
Useful for small installations with few queues and few agents managing themselves.
Using openvpn though. and openbgp. The trick is to use tap interfaces instead of tun, not to define routed networks and let the bgp take care of that (or use load balancing if you will).
Yep, even though all known methods do not work on latest firmwares, it is still possible to root it. General idea is to share /etc over NFS, mount it, edit password/shadow and root the box. For details, look up my e-mail and send direct inquiry.
So they fixed it. And apparently I kinda helped to track it down.
It is broken a little bit. Well, not exactly app_fax, but as it is the only foss component using chan_sip/udptl one might conclude that app_fax is the broken one. In fact it is chan_sip T.38 negotiation that is broken. It does not take in account that udptl does not have one very important variable initialized and relies on optional attribute in sdp to set that variable. If this attribute is not sent by far end, udptl spits out warning and goes on allocating buffer of size -1. Which leads to segfault mentioned in my previous post.