Smoke testing the Mesh-Potato video - Part II

We have now a new over-voltage protection circuit design for the mass production Mesh-Potatos. We were not satisfied with the previous version. Ideally the over-voltage protection circuit has a snap-on characteristic that triggers the fuse and interrupts the supply voltage without a grey zone. The new circuit triggers at 43 Volts and acts as a powerful crowbar circuit. I have connected the prototype of this circuit to a Mesh-Potato and went through the robustness tests according to our test plan. You can find the test plan and the schematic in the svn respository. A little video at Vimeo.com is documenting some of the tests – thanks to Katrin Lang, who acted as editor and camera operator this time.

Mesh-Potato smoke testing with 230 Volt AC from Elektra Berlin on Vimeo.

The list of tests included a reverse DC voltage test from a unfused 36 Volt source (consisting of three powerful 12 V lead acid batteries in series), excessive DC voltage tests and finally a really scary test involving 230 Volt AC (330 Volt peak) from mains. Please don’t try this at home. Even if the Mesh-Potato survives, there is a 50% chance that you might have mains potential on ground of all components connected to the MP. Also don’t try this with your alpha or beta series Mesh-Potatos, because the previous over-voltage protection circuit is not up to that challenge.

Technically inexperienced people can easily make mistakes, so our idea was to design the Mesh-Potato as robust as possible. In 2005 I was helping to set up a large scale WLAN network in the Sylhet area in Bangladesh. The network consisted of high towers (up to 100 feet tall) and strong directional antennas, interconnecting towns and a school with wireless long shots (up to 32km). One of the trainees damaged a important wireless relay on a tower by taking the open ends of a 12 Volt cable and plugging it straight into the mains socket. Of course the equipment (a Mesh-Cube from 4G Systems) subsequently looked like a lightning strike had hit it, which was actually what I supposed first. However there had been no thunderstorm in the night before. It took me a while to find the reason. The trainee either hadn’t realized what he had done, or he didn’t want to admit it. He watched me trying to find the problem without saying anything. It is common practice in Bangladesh to plug cables into sockets without plugs. The quality of sockets and plugs is miserable, so loose contacts are the rule, not the exception. Now a important relay was down and it was hard to get a replacement. The problem wasn’t so much the financial loss. Shipping and particularly customs can take weeks in Bangladesh. So during the first Villagetelco workshop I suggested to design the MP as robust as possible.

Village Telco at linux.conf.au (LCA) 2010

I have just returned from LCA 2010 where I presented on the Village Telco and manned a Village Telco booth on the Open Day. Very good response and lots of people would like Mesh Potatoes! Check out my LCA 2010 blog post for more.

Mesh Potatoes at the LCA 2010 Open Day

Mesh Potatoes at the LCA 2010 Open Day

Potato on the Jetty - Range testing PCB Antennas

Today we made some phone calls over a 400m link using PCB antennas.

We want to use etched PCB Wifi antennas for the Mesh Potato. However we have heard that some companies have had problems with PCB antennas, such as variable results in production. So before committing to PCB antenna we wanted to do some more tests.

Joel is a local hacker here in Adelaide who happens to live at the top of a 4 story apartment block in a beach side suburb called Henley Beach. This gives him good line of sight to points on the ground several hundred meters away. Much easier than testing at my place which is on dead flat terrain and requires masts for any Wifi range testing.

Before heading out to Joel’s place I tried some tests in my backyard. I set up two MP01s about 10m apart. First I connected conventional sleeve dipole (rubber ducky) antennas and measured the signal strength. I then connected a couple of PCB antennas and repeated. To monitor signal levels I wrote a simple script to dump the Received Signal Strength Indication (RSSI) levels (in dBm) from MadWifi:

#!/bin/sh

while [ 1 ]
do
wlanconfig ath0 list | grep 56:ac:90 | awk ‘{ print $6 }’
sleep 1
done

The grep filters out the last few MAC digits of the MP we are interested in, otherwise you get RSSI measurements of all nearby Wifi devices.

However the results were inconclusive and after an hour I became frustrated:

  • On a good test both MPs would receive about -30dBm, however if I moved a MP 20mm a level could drop to -44dBm. Lots of multipath in my back yard!
  • One MP was consistently around -30dBm, whereas the other would move between -30 and -48dBm. Maybe they had different diversity antenna settings. Or maybe the RSSI measurements can’t be trusted.

I had much better (and less frustrating) results using the spectrum analyser to measure signal strengths, as explained in the previous post on PCB Wifi antennas.

In the end I figured it was sufficient to test from a system level rather than attempt more measurements of antenna performance and signal strength. The $64 dollar question is can we make phone calls over a reasonable distance with these antennas?

On the Beach

We placed one MP01 on Joel’s balcony. I then walked down to the end of Henley Jetty (Joel has previously managed to pick up his home Wifi there). There is (just) a line of site between the two points – through a gap in a couple of buildings. The distance was 375m. We used two calibrated V1.2 MP01s (same design as the Beta units). An “iwlist ath0 scan” showed 9 other Wifi networks in operation.

Google Map of Range Test - 375m

One MP01 on Joel's Balcony

I tried a bunch of antenna combinations, starting with regular sleeve dipole (rubber ducky) antennas then moving to PCB antennas first at one end, then both ends of the link. From our previous tests both the sleeve dipole and the PCB monopole antennas have an estimated gain of 2dBi.

We had a total of 4 PCB antenna samples (a mixture of the 17mm and 20mm monopoles) as we wanted to get a feel for performance spread over multiple antennas of the same design. Here are the results:

MP01 #36 MP01 #38 Call Quality
Sleeve Dipole Sleeve Dipole Great
Sleeve Dipole #3 17mm PCB monopole Great
Sleeve Dipole #2 20mm PCB monopole Great
Sleeve Dipole #4 20mm PCB monopole Great
#1 17mm PCB monopole #4 20mm PCB monopole Great
no antenna #4 20mm PCB monopole No Call

The final test was just to make sure we weren’t kidding ourselves.

MP01 on the end of Henley Jetty

At one stage a fisherman assisted in my propagation experiments by standing right in my line of site and lowering a metal net as I talked to Joel!

For each call I tried moving the MP01 (with PCB antenna attached) around. For example upside down, side to side, rotated it. No break up of signal, good audio in both directions. Only problem was wind noise. Joel suggested we add digital noise suppression but I figure there isn’t much wind noise inside village homes!

Here is the view of the far end from either side of the link. The arrow shows the location of the other end.

View of Jetty from Joel's Balcony

View of Joel's Balcony from Jetty That's him with the brown eyes.

First Beta Mesh Potato

Joel is helping my Village Telco presentation at the upcoming LCA 2010 conference so I took a couple of the first Beta MP01s down to his place for a test drive. They are fresh off the production line and not even calibrated as I needed them in a hurry for LCA 2010. Atcom are currently assembling, testing and calibrating the Betas which will be shipping over the next few weeks.

The first Beta Mesh Potato

These early Betas are running revision 203 firmware, which has Afrimesh as the primary GUI with Luci available for “advanced” configuration options. Thanks Elektra and Antoine for your fine work on the Mesh Potato GUI.

Here is Joel’s experience – our #1 Beta MP01 tester! Joel is pretty geeky (he has contributed for several years to the OLPC project) but has never used a Mesh Potato before. I hope this information will be useful for other Beta testers who should be getting their Mesh Potatoes over the next few weeks. I stood back through most of Joel’s beta experience – I wanted to see how other people approach the Mesh Potato.

How Joel Configured His Mesh Potato

  1. The default Ethernet IP is 192.168.1.20. Joel plugged a cross over Ethernet cable into the MP01, although a regular cable should be OK.
  2. He then logged in via telnet, and set the password from the command line using the “passwd” command. Setting the password activated ssh and disabled telnet. This password also becomes the web admin password.
  3. Joel then pointed his browser at 192.168.1.20 and the Web GUI came up.
  4. He changed the 10.130.1.20 “IP Address” to a unique IP on the mesh. Joel selected 10.130.1.123. This is the only change you need to start making phone calls between Mesh Potatoes. This IP address becomes your phone number, for example dialing 123 on the mesh will make Joel’s phone ring. Note this only changes the mesh Wifi IP – the Ethernet IP is still 192.168.1.20. The Ethernet IP can be changed via the Luci Network Menu.

    Setting the Wifi IP on the Mesh Potato

    Note the settings are applied automatically – there is no “save” button, although I understand that this will be present on later firmware as out of habit we all look for a save button! To apply the settings (i.e. change the actual Wifi settings) we rebooted (power cycled) our MP01.

    We also changed the Wifi channel and BSSID to match the mesh settings of a couple of earlier Potatoes. This is not really necessary, the default Wifi channel and BSSID are probably OK for you.

That’s it – the main step is just change the mesh Wifi IP to something other than 10.130.20. Then reboot and you can start making calls between Mesh potatoes.

Easier Configuration

A slightly easier way is:

  1. Point your web browser at 192.168.1.20, login with user/password root/admin.
  2. Simply change the Wifi IP from 10.130.1.x to 10.130.1.yourchoice.
  3. Power cycle your potato.

Configuration without a Web browser

  1. Power up your Potato and connect a phone, after about 1 minute you will get dial tone.
  2. Dial CONF (2663) and you will hear HAL 9000 talking to you!
  3. Enter the new Wifi IP, e.g. 10*130*1*123

Joel asked a good question – what do all the LEDs mean? They are not labeled although from memory it’s power/Ethernet/Wifi activity etc. I asked Edwin@Atcom about this and the reason was the vinyl labels hadn’t arrived when the first few betas shipped. The rest of the Betas will have these labels for the LEDs.

Simplified Management for A2B and Villagetelco

Following the release of A2Billing 1.4.4 stable the 14th of December, we have released the Simplified Management Interface for the release. The Installation Wizard and the Simplified Management Interface and part of a larger effort to simplify pre-paid billing for the Village Telco.

Code for the simplified wizard to be applied over the current A2Billing Administration GUI is available here:

http://www.it46.se/svn/villagetelco/a2billing/gui/release/

Enjoy the winter solstice. From the land of -10 C Happy Yule-tide! http://en.wikipedia.org/wiki/Yule

Antenna Testing

Jeff and I have just had an enjoyable day outside testing candidate antennas for the Mesh Potato. Our goal was to evaluate candidates for the internal antenna of the production Mesh Potato.

Jeff designed three types of antennas which I laid out on PCB and had fabricated locally. The three designs were a dipole, a monopole, and a biquad (single loop). We made three versions of each PCB antenna with slightly different dimensions.

I also made a some wire antennas, a monopole, a biquad (dual loop), and a quad (single loop).

Our PCB and wire antennas

PCB Biquad Design

PCB biquad design

PCB Monopole Design

PCB Monopole Design

Checking the Antenna Impedance

When the PCBs came back the first step was to check the impedance of each antenna. We want roughly 50 ohms impedance to ensure the maximum amount of power is transferred from the Mesh Potato transmitter to the antenna.

A Standing Wave Ratio (SWR) bridge can be used to measure the SWR. I used a version of the design by Erwin Gijzen, a radio Ham and Wifi experimenter. I constructed the SWR head, and measured the DC voltage from the bridge using a multimeter. The bridge compares the impedance of the antennas to a known 50 ohms impedance. If they are equal then the DC output from the bridge should be 0V. Various degrees of mis-match give different output voltages.

SWR head

SWR head, microwave PCB made with a Dremel tool

I constructed the bridge from double sided PCB and cut the microstrip (3mm wide on 1.6mm thick FR4) with a Dremel tool to save time. When tested it gave sensible results once I fitted a decent microwave detector diode. Unlike Erwin I couldn’t null it down to 0V with a reference 50 ohm load but it did give indicative readings that enabled me to compare our antennas to reference antennas and determine if they had a reasonable match to 50 ohms.

Here are some results:

Load SWR bridge output (VDC)
50 ohm dummy 0.5
short circuit 1.3
off the shelf router antenna 0.5
17mm PCB monopole 0.5
20mm PCB monopole 0.7
34mm PCB dipole 1.3
64mm PCB biquad dual loop 1.3
68mm PCB biquad dual loop 1.4
72mm PCB biquad dual loop 1.5
wire biquad dual loop 0.8
wire monopole 0.6

The 17mm and 20mm monopoles look good, close to the reference 50 ohm load and commercial off the shelf router antennas (which have sleeve dipole construction internally). The wire antennas also look good. The PCB dipole and PCB biquads don’t look so great.

I tuned the wire monopole to a low SWR by snipping off bits of wire, 0.5mm at a time. I started with a length of 31mm (free space quarter wavelength at 2.4 GHz) but found a good SWR at 26mm. This is probably due to the dielectric constant of the insulation on the wire affecting the wavelength.

Antenna Test Range

I constructed a test range in my back yard, along the lines discussed by Erwin. I used a Nanostation 2 at the transmitter, sending continuous 802.11b broadcast pings as described here. The antenna under test was placed about 6m away and a spectrum analyser used as the receiver. It wasn’t a very good antenna range but after some experimentation we did get surprisingly repeatable results when we compared our antennas to several control antennas.

I fashioned a clamp on a tripod to hold the antennas:

Tripod and clamp

Tripod and clamp

However the tripod and clamp didn’t work very well. When I swapped antennas the results differed wildly in exactly the same position. It’s hard to place a 17mm printed monopole in the same position as a 80cm colinear antenna as their sizes are so different.

So instead I moved each antenna around by hand until I found the peak amplitude, which was captured by the “max hold” function of the spectrum analyser. Sounds a bit rough but gave good repeatable results, and Jeff and I achieved similar results when testing.

Path Loss

The 802.11b signal peaked at about -30dBm on the spec an. Using the Wifi power measurement method described here this means a total received power of -20dBm.

The expected received signal is:

Pr = Tx power + Tx antenna gain – path loss + Rx antenna gain – coax loss

So we plug in the numbers from the Nanostation 2, a 6m path loss and the 8dBi gain Superpass omni reference antenna we get:

Pr = 16 + 12 – 56 + 8 -1 = -19dBm

which is pretty close to what we are measuring using the spectrum analyser. If only all my calculations came out this close!

Antenna Gain Results

We used the 8dBi Superpass as a reference. We would first measure the signals from the Superpass, then save that on the screen as signal A. We would then measure the test antennas and calculate the antenna gain based on the known Superpass gain. We moved each antenna around by hand until a peak was found (the max hold function made this straight forward).

We repeated these tests several times over the day, and while the absolute levels would change 1-2dB the relative levels were always similar.

The antennas are listed in order of gain, and I would estimate the measurements have a tolerance of +/- 1dB. The RF level is the peak of the 802.11b signal on the spectrum analyser.

Antenna Rx Level (dBm) Gain (dBi)
15dB grid antenna -24 14
wire (two loop) biquad with reflector -26 12
8dB Superpass -30 8
wire (two loop) biquad -34 4
wire (one loop) quad -35 3
wire monopole -36 2
17mm PCB monopole -36 2
20mm PCB monopole -36 2
commercial router antennas -36 2
72mm PCB biquad dual loop -40 -2

Discussion

The location of the physical position where peak received signal was found was quite “sharp”. This may have been due to lobes in the signal from the Nanostation 2 or multipath.

Several commercial router antennas were tested (sleeve dipole construction), they all measured about the same. The internal design of these antennas is discussed here.

The results from the control antennas (15dB grid, 8dB Superpass, and nominal 2dB sleeve dipole commercial router antennas) are consistent with what we would expect, which gives us some confidence in the other test results.

The impedance match and gain results from the PCB biquad are poor, which suggests the antenna is not resonant at 2.4GHz. It would be nice to test this antenna on a network analyser to find out where they are resonant (please contact me if you have one – I will ship an antenna to you!) Jeff is working up a simulation of the PCB biquad to test the design. We aren’t pursuing the PCB dipole as we have a bunch of antenna candidates that perform just as well (2dBi).

The wire biquad performance with a reflector was remarkable, nearly as good as the grid antenna which is a much larger antenna. The measured gain (12dBi) is consistent with other peoples results for this antenna.

Jeff and I really liked the wire antennas due to their performance and simplicity. They are easy to make: in production they could be bent up on a jig on 10 seconds from stiff copper wire then soldered to the Mesh Potato motherboard. One small problem with the dual loop biquad wire antennas is a feed arrangement – a small piece of coax would be needed to reach the central feed point. We don’t want the antenna wire directly over the PCB, as this would affect performance. The single loop wire quad is simpler in this regard, as it could be attached at one corner to the PCB.

The PCB monopoles perform well and are very simple, just a 17mm x 3mm track on the PCB next to a good chunk of ground plane. Virtually zero cost to add to the Mesh Potato motherboard. Both the 17mm and 20mm versions worked well, which suggests a relatively wide bandwidth and a high tolerance to small variations in manufacture like dieletric constant of the PCB substrate. Antennas fabricated on PCB are physically smaller than their wire cousins as the signals travel slower which means a smaller wavelength for a given frequency.

Wire single and dual loop biquad/quad antennas had above average gain and some directivity, with both peaks and nulls evident as they were rotated. Is directivity a good thing for a mesh router? You might enhance the signal of one node but null out the signal from another. I am not sure.

The higher gains of some antennas look attractive but may not be useful in practical mesh networks. To achieve the highest gain required careful adjustment of the antenna position. This is fine in a traditional point-point Wifi link, but in a mesh network their are multiple nodes we want to talk to. So if you peak the response to one node, you may dip the response to another. I guess it depends on how many nodes you want to talk to.

The reflector was a piece of blank PCB about 20cm x 20cm. It was moved back and forth behind the antenna until a peak was found (usually at around 15-20mm). All antennas improved by at least 4dB with the reflector, the wire biquad improved by 6-8dB. David C has suggested a slide-in reflector arrangement to give a choice between omni and directional antennas. These tests confirm David’s suggestion is a good one, if a precise way to mounting the reflector can be found.

Here are some of the antennas tested grouped by gain.

Antennas grouped by gain

Antennas grouped by gain, highest gain on the left

A2Billing with Village Telco

We are pleased to announce the release of A2Billing 1.4.4 (http://www.asterisk2billing.org).
Our new release contains a lot of enhancements for the Village Telco Project.

As a result of the Village Telco project, we have 2 new customer API’s to create a trunk config and to retrieve rates from an A2Billing platform, those 2 APIs will become useful for Voip’s Provider willing to supply Termination for the VT project.

Despite of those 2 APIs, a numerous amount of web service has been created to assist the Auto provisioning service, see the doc here :
https://docs.google.com/Doc?docid=0AX-tdmlhxGGBZGh0bmtncTZfMGN6aGh6Z2Zy&hl=en

Our new release 1.4.4 is the first “Stable version” including the first effort for the Village Telco, much more will follow on Security and monitoring, let’s just hang until the release.

Billing calls from potatoes (Part III)

Here it comes the last posting of the “Billing calls from meshed potatoes” sequel.

Coding is an interesting exercise of long term investment. In fact, “for every minute spent in organizing, an hour is earned”. In October 2009, Areski (A2Billing) visited IT46 in Stockholm. There were two main answers to our “easy billing” challenge: a quick hack that will never be reusable or to add an API to A2Billing so other applications could be build in the future.

The “quick hack” consisted in collecting the information from the user (the Installation Wizard GUI) to later alter the SQL database (dump a bunch of nasty INSERTS!). The other alternative (the nice one) was to build an abstract layer at the top of A2Billing that could perform several “primitives” on behalf of the wizard.

We spent a couple of days with pen and paper, starting with the technical requirements of the Village Telco. Finally, we concluded that an “ugly hack” was going to give us more problems in the long round… so we took the decision to build something that we should not be embarrassed of in the future. After all, open source is the result of peer pressure. :-D .

We decided (1) to build the Installation Wizard using a MVC framework (Cake PHP), (2) to use SOAP as a transport mechanism between the Wizard and A2Billing, (3) extend A2Billing to support our general API.

This was a very nice arrangement, Areski could concentrate in building the internal logic. There are so many tables in A2Billing that I still wonder how Areski could figure out what everyone is doing!. In our side we decided to concentrate in building the Wizard (full of round corners!). The Installation Wizard should be based in the well known user-friendly principle of (Next, Next, Next, Accept).

Louise has been programing intensively with Cake PHP for the last 6 months, and she did not want to write the code in anything else. It has been a very nice programming project, the new API glued all together… and every day we were figuring out a way to reduce the number of clicks that the user need to put the scenario up and running.

Our main finding was that there is still plenty of work to do in the provisioning of VoIP upstream providers and the potatoes themselves, when it comes to upstream providers our goal is to make sure that the user does no need to type any SIP parameters at all into the system (account, password, codec, etc). The wizard will present to the user a set of VoIP carriers and by means of an activation code the system will auto-provision! (One click!) There is plenty of things that can go wrong… when hooking our local telephony mesh to an external gateway… and that means lots of code inside.

For the curious this is the last step of the Installation Wizard before launching the final installation against A2Billing.

Today, we can bill local calls with a few clicks and it is time to start thinking in the overall provisioning!. Provisioning, it is definitely a Village Telco component that it is going to need more than our brains! We are getting there, it is easy to forget that one year ago we were just imagining something like this! :)

Stress Testing the Potato

I’m currently performing “Africanisation” tests on Mesh-Potato prototypes from the alpha and beta production run. “Africanisation” means that a Mesh Potato is supposed to survive even if you accidentally feed reversed DC polarity or AC to the DC jack, to any pin of the Ethernet port or FXS port. For a couple of weeks before the Capetown workshop I had only one Mesh Potato to perform software development, radio performance and hardware tests. I was therefore quite nervous to break one of these devices, so I didn’t do any – possibly destructive – tests. The first sample of the MP 1.2 units has arrived at my home this week. Now I have three MPs – time to take them and put the design goals to a smoke test! In the little video linked here I’m connecting a – unfused – DC cable with reversed polarity straight from a lead-acid battery to a MP. Don’t try this at home with your equipment, folks! Never operate with unfused DC wiring, particularly if you connect it to a lead-acid battery, since it can feed up to several hundred Amps into your circuit and cause a fire!

Billing calls from potatoes (Part II)

In November 2008, Steve, Louise and myself sat down in Irene (a small “township” south of Pretoria) and started to draft what we considered a billing scenario for the Village Telco. A few nice ideas came up from that meeting: the relevance of local calls, voicemail, the possibility to switch your potato from pay phone to personal phone, focusing on pre-paid models, etc.

Can we take a VoIP billing software and make it simple enough for our expected Village Telco scenario? This is not a trivial question to answer, what is “simple enough” and what is relevant to our target group? I like to explain usability and business models taking the asterisk GUI and linksys wireless AP as an example. What is better, to have a software that can do almost everything you want but only a few can configure correctly or a solution that does something very concrete out-of-the-box?

I call this the “asterisk vs linksys”. Steve prefers to call it “drupal vs wordpress”. Someone will accuse me of opening a topic that can lead to a DNFTT situation (Yes!, look for the term DNFTT and you will see what I mean). In any case, our gut feeling is that we needed the “wordpress of billing”, something that is simple enough, with default values to fit our scenario. It won’t do everything, it will do a few things very well. What I did not know at that time is how much time and energy can take to make things simple for others to use! It remind me those times when you needed to know the horizontal input frequency of your screen to get your graphical interface running. Can we make billing simple? Can we make it to work out of the box without imposing users to understand the meaning of codec, trunk, SIP, challenge-response or MD5 hashes? Can we survive the flame-wars of the geek community insisting that users needs to know advance cryptography to run a secure VoIP call?

In September 2009, we had a clear understanding of what simple billing could look like and what two big pieces of code were needed for A2billing: (1) an installation wizard, (2) a simplified management interface.

So we put together a document including the seven technical requirements of the installation wizard:

R1 Billing

  • The main billing system will be pay-as-you-go
  • The system should provide mechanisms to avoid fraud

R2 Connectivity

  • The VT and billing platform does not depend on an Internet connection
  • No Mesh Potatoes or Upstream Providers need to be active to configure the VT billing platform
  • The wizard will assume that the upstream provider is reachable via IP/SIP
  • Other trunk technologies as GSM, PSTN, will provide a SIP interface to the a2billing system

R3 Client Hardware

  • The Mesh Potato will be the main hardware and can operate in two main modes home/business phone or pay phone mode
  • A client device should have the ability to operate in one or two modes

R4 Client Types

  • Three types of accounts need to be supported in the system
  1. account only: customer has an account with credit into the system
  2. phone number# only: customer has a phone number but not a physical phone
  3. phone: customer owns a phone with a # and an account associated with it

R5 DID

  • The system can support 0,1 or N (many) DID numbers. When DID numbers are more than 1, we assume a pool of numbers

R6 Voicemail

  • Any person with a DID (external or internal) should have a Voicemail
  • Voicemail should be reachable by any phone

R7 Callplans and Rates

  • The selection of the provider, implies the automatic creation of a rate plan associated with the provider
  • Users should not have to deal with dialplans in asterisk, including all main contexts: call outs, recharge, did, voicemail

Time to move the specifications into an architecture model!

Extending A2Billing to support our Installation Wizard

The picture (green area) shows what A2Billing provides by default. Changes to A2Billing (as getting a basic scenario up and running) require accessing the web GUI.

The Village Telco has extended A2Billing to include (1) our Simplified Management Interface and (2) a Web service that talks with A2Billing internal logic. This new Webservice presents a API that hides the complex SQL back office logic.

The idea behind this new (abstract) layer of communication with A2Billing was to allow the design of third party applications that can perform complex tasks inside of the Billing Platform. The new API currently consists of 26 functions that are accessible via a SOAP interface.

Our Village Telco Installation wizard makes use of the newly developed API. With this approach, the Installation Wizard does not need to know anything about A2Billing’s SQL :-) . Hopefully, any changes inside of the internal logic of A2Billing will not break our Wizard.

So how the wizard look like?

Simple… full of round corners and performs a default installation of a local Village Telco A2Billing in 12-17 clicks!

Screen shoots follows in Part III

References

[1] A2Billing Webservice API

https://docs.google.com/Doc?docid=0AX-tdmlhxGGBZGh0bmtncTZfMGN6aGh6Z2Zy&hl=en

[2] Installation Wizard Development SVN

http://svn.it46.se/svn/villagetelco/a2billing/wizard/

[3] Simplified Management Interface SVN

http://svn.it46.se/svn/villagetelco/a2billing/gui/

[4] A2Billing Village Telco Contrib Branch SVN

http://svn.a2billing.net/svn/asterisk2billing/trunk/addons/contrib/villagetelco/ (user/passwd: guest/guest)