(Still) no satisfaction

It makes no sense to repeat the lyrics from Rolling Stones’ Satisfaction here. It’s a great song alright, but for some reason all that’s been left from it in my own mind is that recurring motto “I can’t get no”, which Mick Jagger shouts out angrily, over and over. That’s about my feeling, too, when trying to get my first Open USB FXO prototype to work: no satisfaction…

To take over from where I left in my previous post, it seems that the BAV 99 between the ICSP pinheader connector and the PIC is indeed a barrier to programming the 18LF2550 in-circuit using FDART2003 and WinPIC800. I have conducted a couple of web searches, trying to grasp how these two, the 18LF2550 and the FDART2003, get along with WinPIC800 as a programmer. The search showed that, although WinPIC does not reference the 18LF2550 as a supported chip, various people around have programmed successfully 18LF2550 PICs using the FDART2003 and WinPIC combination.

The only possibility that this left me with was that my circuitry with the BAV99 prohibited ICSP-programming the PIC on-board, at least with this programmer. This, in turn, meant that if I wanted to test my prototype design, I had to either change the culprit circuitry (e.g. providing a jumper that would bypass the BAV99), or to replace the PIC with another, pre-programmed one. Of course, if I chose the second path, I ‘d have to somehow pre-program another 18LF2550 — I am not good at unsoldering ICs without destroying them.

But wait — sure I could program another PIC. The First Principle for Prototype Designers states “One equals none”, and I had taken that very seriously: I had ordered materials for three prototypes, so there, sitting nicely in the pouches from Mouser, were another two 18LF2550. And I still had a host of un-populated Open USB FXS boards, which I could use as ICSP programming boards. All I had to do was to solder the RPGM resistor and short-circuit jumper J1. Then I ‘d have to place the PIC and hold it firmly on-board, and I ‘d be able to program it!

Naaaahh, might you think, that sort of thing will never work. Let me tell you: it had indeed worked in the past, because that’s exactly how I programmed all Open USB FXS PICs before soldering them for my first prototype bunch. So I was confident that I had a chance going down this path.

My first attempt though gave — no satisfaction. The WINPIC refused stubbornly to auto-detect the 18LF2550. But then, I decided to be more insistent than the damn PIC. I tried again, this time holding firmly with my hand one of my old PIC18F2550’s; it worked at once, revealing to WinPIC800 its internals. Well that couldn’t be… I tried again with the 18LF2550 and, bingo! It was recognized (as a 18F2550)! For some reason, the 18LF2550 needed more pressure force to make good contact on the PCB.

I programmed both my two remaining 18LF1550’s. Then I started with removing the unprogrammed LF2550 from the board by cutting the pins and removing the remnants with a soldering iron. I tried my best to cut the pins as gently as I could, but I still ruined a couple of pads. No problem; after soldering the new PIC in place, I soldered a couple of small wires right from the pins whose pads I had destroyed to the corresponding signals.

Then I tested the circuit. Which, you guessed it right, gave — no satisfaction… The PIC refuses to start. A few quick measurements show that the voltage at the cathode of the BAV99 is 3.9V which is OK (note that, when the circuit starts to work, it will draw some current and I expect the voltage to drop a bit, down to 3.5V or so). Well?

All that crosses my mind is “I can’t get no [the damn thing to work], ooh, no, no no…, no satisfaction… no satisfaction…”.

Admittedly, it’s too early. I need to conduct a thorough electrical test, and then I will again review my schematic to see if there is some glitch there. However, I thought this time things would be easier. Reality shows they are not. Stay tuned, there should be some news sooner or later!

Advertisements

5 Responses to “(Still) no satisfaction”

  1. Ricardo Landim Says:

    Congratulations Angelos…

    I am here to remember the David’s words… “95% of project is software”!

    I’m tuned!

  2. gerardo Says:

    very interesting development, what happened since? did this project stopped?

    • Angelos Varvitsiotis Says:

      Hi Gerardo,

      I am deeply sorry I did not notice your comment earlier. Yes, this project is practically inactive. As you can see, I am still replying comments (on an irregular basis, though), however I have not put any effort in it for quite some time now. Anyone interested in taking over?

      Regards,

      Angelos

  3. kostbill1234 Says:

    Καλησπέρα!

    Ψάχνοντας να βρω κάτι σχετικό έπεσα στο blog σου.
    Έχω κάποιες ερωτήσεις σχετικά με FXO, μπορείς να με βοηθήσεις να καταλάβω κάτι που δεν είναι για την ώρα φανερό;

    Η ερώτηση έχει να κάνει με τον τρόπο επικοινωνίας ενός FXO με τον IPPBX Asterisk, αν ξέρεις να βοηθήσεις θα είναι μεγάλη βοήθεια για εμένα.

    Ευχαριστώ πολύ,
    Βασίλης.

    • Angelos Varvitsiotis Says:

      Hi Vassili,

      [This comment is in Greek, so I will translate the question: Vassilis (or Bill, if you prefer) is asking if I know the way that an FXO port communicates with the Asterisk IPPBX].
      Yes, well, it depends. The “FXO” specification is not about how a port communicates to the IPPBX, but about how it commuicates to the Telco world. The FXO specification comprises voltage, current, resistance, capacitance and timing specs that a device must obey in order for it to plug to your Telco RJ-11 at home and cooperate with the Telco’s PBX.

      Now, about the other end – there are again two things. The first is, how an FXO device communicates hardware-wise to your computer running the IP PBX. This could be PCI, USB, Ethernet, or whatever else. The second is the type of the “channel” that the device uses to communicate with Asterisk. Asterisk supports a number of different low-level protocols for communicating with devices. In my design, this would be the Dahdi channel (see Open USB FXS as well).

      Implementing a Dahdi channel driver in a Linux device driver means that the driver must (a) support some generic Asterisk channel driver functions and (b) support some specific Dahdi channel driver functions. Most of these are callbacks, i.e. Asterisk calls them to read PCM data, write PCM data, check if the FXO device is ringing, set on- or off-hook conditions, and so on. I hope this gives the general idea. For more, you should really read the code of some dahdi (or other channel) device driver, including my Open USB FXS.

      Regards,

      Angelos

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: