|
||||||||||||
|
|
We have made good progress on the Mesh Potato (MP) so far. The basic functionality (making phone calls over a Wifi Mesh network) is working OK. Over the past few weeks Elektra and I have been concentrating on several specific areas of the MP and testing them in more depth. This posts focuses on some of the tests I have performed, the bugs found, and the final results. Stability One simple stability test is uptime. I have left both my MP prototypes running for up to 5 days at a time with good results – Linux and Wifi stayed up, and we still had dial tone from the FXS port. This simple test says a lot: e.g no memory leaks, CPU instability, drastic over temperature problems. Another test I like to do to all my telephony devices is hammer them with phone calls for 24 hours. Here is the test set-up:  Stability Test An x86 Asterisk box acts as the call generator. It starts a new call to the MP. When the MP receives the call it starts the FXS port ringing. Another Asterisk box (an IP04 with an FXO port) answers the call, plays a prompt for a few seconds, then hangs up. The entire sequence is then repeated – make thousands of calls over a 24 hour period. The SIP call is placed over Mesh Wifi to make sure all parts of the MP system are being exercised. This test gives the MP quite a hard time as much of the call processing load is involved in set up and tear down of calls, and unless you are my teenage daughter you can’t really make 3500 calls in 24 hours. When I started the tests it threw up problems nearly immediately – Asterisk was seg faulting with no feedback as to why it was crashing. This led to a week of fun and games where the problem was eventually traced to thread problems in the Asterisk channel driver I had written (chan_mp). This channel driver has been a painful experience for me (even though I have written a few before), and has taken perhaps 3 weeks of part time work to write and debug. Lots of fun with threads and null pointers. Even now I still don’t quite understand all the issues around Asterisk channel drivers. I would appreciate a code review of the driver if there are any Asterisk channel driver experts out there. Anyway I finally tracked down the source of the problem and modified the channel driver. It passed the 24 hour stability tests and made 3500 calls. Mesh Load Test This is a repeat of the load test from Phase 1 of the Mesh Potato Project, but this time on the actual MP hardware with the FXS driver running:  Mesh Load Test A big difference between the Village Telco and Cell Phone network is no base stations (Cell Phone Towers). Instead, the calls are routed via the client nodes. It’s a peer-peer network rather than a client-server architecture. The idea of this test is to make sure that a given mesh potato node can relay 15 phone calls for other people while simultaneously making a phone call of it’s own. This scenario places significant CPU load on the router due to the number of Wifi packets that must be processed at the same time as DSP intensive code like echo cancellation and speech compression. The set up details of this test are on the wiki and have been blogged about earlier. Speech quality was fine, and loadav about 0.71, similar to the Phase 1 results. Occasionally I could hear some packet loss but overall the call was fine. A good result considering all that processing (Linux, Wifi, mesh, Asterisk, echo cancelling, GSM speech compression, FXS driver) on that little router chip! One interesting fact is that even with a total of 16 calls the bit rate is only around 500 kbit/s, so the bandwidth of the mesh is quite lightly loaded. However speech packets are rather short, so raising the number of phone calls would likely run into CPU load (rather than Wifi bandwidth) issues due to the per-packet processing load. Wifi Range Test Wifi is mainly the domain of Elektra and Jeff on this project but I was keen to get some rough idea of how well the radio was working. I had made a few calls around the house OK but noticed that the received signal level was quite low. A bit of thought led us to a static protection diode we had placed across the antenna circuit. Although a good idea for the RX side it was conducting when transmit signal was present. After removing this diode the TX level jumped right up to roughly comparable levels to a DIR-300 router that uses the same Atheros AR2317 SoC. However using radiated signal levels it is hard to get consistent results, they bounce around all over the place. Jeff suggested connecting a combination of DIR-300 and Mesh Potatoes in A-B tests via cables and calibrated attenuators to obtain consistent measurements. Over a few days I made several attempts at range tests. However where I live is quite flat so it’s difficult to get a good Line-Of-Sight (LOS). I did manage to make phone calls over about 250m which is pretty much what we need for a Village Telco Network. Elektra and I feel the radio performance could probably be improved with some adjustment of the RF circuit components and possibly PCB layout. Elektra has access to a RF test lab later this week so we will get some more concrete information of Wifi performance. One area we really need more information on is radio calibration data and the Hardware Design Guide document for the AR2317, however we have been unable to obtain this important information from Atheros. More blogging to come from Elektra on Wifi radio and power supply performance. Bringing up Wifi On Friday I set about testing Wifi on the two Mesh Potato prototypes. The N-type antenna connectors attach to the MP PCB via a pigtail with a tiny Hi-rose style connector. This looks a bit fragile so I decided to mount the two MPs in some weatherproof boxes so I had a firm mounting for the antenna pig tail. I chose one metal and one plastic, to see if the case material makes any difference to the Wifi performance. They wont be completely weatherproof (I’ll just run the phone power, and Ethernet cables through holes), but enough to take outside for some tests and withstand some handling. I mounted both the PCB and the antenna connector in the lid, so the whole assembly can be removed without putting any strain on that tiny PCB antenna connector. Only problem is I can’t see the LEDs – will need to make a little window on the bottom of the box.  Mesh Potatoes mounted on box lids Having secured the antenna connector I brought Wifi up. I thought I would take the small, sensible step of trying to associate with my home Wifi network first. It was all looking good until my MP seemed to slow down then stop responding entirely. Then my laptop (also connected via Wifi) started to slow down and lost Internet connectivity. Oops, routing loop between Ethernet and Wifi on the Mesh Potato! Didn’t know you could bring down a whole network that way. As Wifi was coming up automatically on boot it was hard to stop, so I ended up re-flashing the router and going straight to Batman. This came up straight away and I had two MPs and a Nanostation happily meshing with each other. The blinking of the two Wifi lights as batman sends out messages every second is mesmerising Voice Over B.A.T.M.A.N. After a bit of messing around with Asterisk conf files I made a MP-MP phone call over Batman and the Mesh Network. The audio in one direction was fine but a little distorted in the other direction. After a break of a few days I took a look at this bug. The problem ended up being the Asterisk channel driver, it was accidentally sending both RTP audio and ring tone to the FXS driver during a call, i.e. ring tone wasn’t being switched off when the call was answered. This was overloading the FXS driver FIFO and causing distorted audio. Curiously, it worked OK until I tried a call over Wifi. Anyway I have fixed this bug now and tested a few different codec configurations over the mesh including ulaw, gsm with 20ms frames, and GSM with 80ms frames. We can also make calls between a MP and a SIP phone connected to the Ethernet port of the MP. The load av is around 0.5 during a call (using the GSM codec). Here is a block diagram of the test setup. The Laptop is used for monitoring. It’s cool that I can ssh to the remote MP over the mesh network and mess with Asterisk conf files, run top etc.  MP tests for first calls over the mesh The audio sounds great. We can’t hear any echo, thanks to the Oslec echo canceller which seems to run fine on this platform. To stress the system a bit I tried ping flooding from my laptop. This affected the audio quality but the call was still very intelligible. Like driving under a bridge with a cell phone. This is interesting – perhaps a mesh potato network will have a “soft” degradation of quality as network traffic increases. Call quality will drop a little, but the network may not fall over. The reliability of the Mesh Potato hardware has been remarkably good so far. I left the prototypes running for about 5 days, and when I came back the mesh was still running, and picking up a phone gave me dial tone. Can’t complain about that on hardware where the solder has barely cooled! Since the boot loader bugs have been tamed we have been making steady progress. Today I brought the FXS module drivers up, closely followed by Asterisk and the first Mesh Potato phone call at 3:43pm today. Almost exactly 1 year since the Mesh Potato project was kicked off at the first Village Telco workshop in June 2008. Alen from Atcom has been closely following our steps, which has encouraged Elektra and I to write a Mesh Potato How To on the Village Telco Wiki. The good news is we have Linux booting on the Mesh Potato:
RedBoot(tm) bootstrap and debug environment [ROMRAM] Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: ap61 Please press Enter to activate this console. device eth0 entered promiscuous moebr-lan: port 1(eth0) entering learning state BusyBox v1.11.2 (2009-05-18 13:36:36 CST) built-in shell (ash) _______ ________ __  A bee's view flying over the Potato landscape It even picks up the 8M flash, Ethernet works, and the Wifi drivers come up. In the last installment Linux was choking due to an inaccurate estimate of available memory (32M rather than the actual 16M). I spent an afternoon tracking down the cause – Linux on the AR2317 detects the amount of memory by examining a register that the boot loader sets up before Linux starts. Here is the Linux source (arch/mips/atheros/ar5315/board.c): Hmmmm, just after I thought I was free of boot loader issues! Anyway a bit of Googling found another guy in the OpenWRT community who had found and solved exactly the same problem 6 months ago. Thanks Yoonix! The fix involved changing the SDRAM #defines in the boot loader source and reflashing the boot loader. As soon as we re-flashed the boot loader Linux came up straight away. Joel, a local Linux hacker came around to help out. He wrote a little Python script to model the register configuration changes and make sure I didn't type anything too silly while reflashing the boot loader (my record is not good). I also found a neat trick for testing Linux kernel images in RedBoot without reflashing: OK, now time to look at bringing up Wifi, or maybe the FXS port. Or maybe I'll just order some pizza! Since my previous post I have been stuck in “boot loader hell” for 3 days! On day 1 I placed the ap61.rom file and had the MP boot loader working but flash support was missing. So i took the redboot-ap61 code that Elektra had prepared and tried to flash it. Clunk – a dead Potato. Nothing from the RS232 serial and no signs of life. So I carefully retraced my steps and tried to re-flash the MP from JTAG. Still dead. Huh? There followed several days of futzing about, looking at the jtagspi code, trying this, trying that, and getting more and more confused and not a little upset! I just didn’t make sense – if ap61.rom worked the first time why not now?  Mesh Potatoes Maternity Ward On Friday morning I took Elektra’s advice and had a break for a few hours, pedaling my bike into town and back. This cleared my head a bit and I tried a new tack. Prior to receiving the first MP, I had practiced flashing an AR2317 design using an off the shelf DIR-300. So I tried this again and no probs – the ap61.rom code fired straight up on the DIR-300. This told me my flashing procedure and the ap61.rom code was OK. Then I noticed something funny in the ap61.rom boot log from the DIR-300: So this idea popped into my head: 1/ What if Alen (from Atcom) had flashed a boot loader before sending me the MP01? 2/ From my records on Monday, and examining the jtagspi code, I know that my write address for my initial MP01 flash on Monday was wrong: 0×1fc00000 The jtagspi software discards the top 8 bits, leaving 0xc00000. Now on a DIR-300 with 4M the top 2 bits get discarded leaving 0×00000, or the first three blocks of flash. As you would expect. However when I used the same 0×1fc00000 address on a MP01 with 8M flash, I you get 400000, or half way through the 8M flash. So on Monday I think I flashed ap61.rom half way through the 8M flash. When I booted, it ran code from the first 3 sectors, which was whatever was in the SPI flash before I flashed it! So I checked with Alen, and yes he had programmed the SPI flash chips before soldering! So I had been following a blind alley all week – the idea that ap61.rom boots OK on the MP01! 4/ I continued to chat with Alen via IM. Guess what? The MP01s have 8M flash chips fitted – as that is what the reference design had! That also explains why ap61.rom won’t boot – it was compiled for 16M! The mp01.bin Alen used was set up for a 2M flash/8M ram router. You can even see it in the boot log RAM reports: MP01: So with my 3 yrs old in tow I ran down to my soldering tools guy and bought some “chip quick”, a special low-melting-point solder than can be used to remove surface mount chips with just an ordinary soldering iron. Here is a 30 second video of how Chip Quick works. It’s actually good fun to use, and the low melting point is very kind to the PCB. It also saved me a couple of days finding some one with proper SM rework tools (it’s Friday afternoon before a long weekend here). No way I wanted to wait until Tuesday to fix this bug! Now I am pretty geeky, but even I don’t have 16Mbyte SDRAM chips just laying about. So it was time for some open-heart surgery. I removed a 16M flash chip from the “donor” DIR-300, and soldered it onto MP001-001 (the first prototype). I powered up and no power LED – there was a short circuit between 3V3 and GND! Bloody Hell – some days you just can’t win! I looked for the elusive short for one hour then gave up on MP001-001 for now. Instead I turned my attentions to the second prototype, MP01-002. I carefully removed the same precious 16M chip from MP01-001 and soldered it onto MP01-002. No shorts this time. I applied 12V and the boot loader comes alive. YAaaaaayyyy!! As an encore I tried to get Linux to boot….however I had displeased the Gods of embedded systems this week and it was not to be – the Linux image we use for the DIR-300 is stopping part way. For some reason available memory is reported as 32Mbyte rather than the correct 16MByte. However I am going to work on that problem later – time for a few days break!  The first Mesh Potato Yesterday (Monday June 1) the courier arrived with the very first Mesh Potato (MP) prototype, which had been hand assembled by the good people at Atcom. This is always an exciting and risky time in the life of any hardware project, as you don’t really know if it’s going to work. In fact, there is a hell of a lot that could go wrong. Like one solder ball under the Atheros BGA chip not soldered, or a nasty PCB or schematic design error that means another re-spin of the PCB and 1 month delay. Or smoke might come out of the Atheros chip when you first apply power. I have seen all of these on past projects….. Fortunately Alen at Atcom had done some initial tests, like checking for the 3V3 and 1V8 power rails, and making sure the 40 MHz clock was present. So we had some encouraging early signs of life. My initial goal was to get the boot loader to run – this would prove that most of the AR2317 circuit is OK (CPU, RAM, flash etc). I chose the boot loader image (ap61.rom) that we have been using on the DIR-300 router as this router uses the same Atheros AR2317 chip. So I connected the JTAG cable. The CPU was detected (excellent!) and the jtagspi software started flashing the boot loader. This is a slow process (2.5 hours) using my home-brew JTAG cable, so I headed out for a nice Chinese lunch and a walk with my wife! Alright, so we also went to the bakery and bought a custard filled cake. You need energy to hack. Two hours later I returned and tentatively connected the RS232 cable and power up the MP. This is what I saw: No board config data found! +flash_hwr_init: Unsupported flash device - id=22 FLASH: driver init failed: Driver does not support device Sorry, FLASH config exceeds available space in FIS directory Couldn't find valid MAC address for enet0. Using default! Invalid PHY ID1 for enet0 port0. Expected 0x0243, read 0xffff /ar2317-prj/LSDK5.0.2.46/src/redboot_cobra/ecos/packages/devs/eth/mips/ar531x/ccEthernet eth0: MAC address 00:03:7f:e0:02:bf IP: 0.0.0.0/255.255.255.0, Gateway: 0.0.0.0 Default server: 0.0.0.0 RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version UNKNOWN - built 00:32:22, Aug 7 2007 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: ap61 RAM: 0x80000000-0x80800000, [0x80040760-0x807f1000] available FLASH: 0x00000000 - 0x00000001, 0 blocks of 0x00000000 bytes each. RedBoot> This is actually pretty good – the boot loader is running – with a few complaints about the 8M flash and Ethernet PHY. However a running boot loader means much of the hardware must be OK. Nice. I have some RedBoot hacking to do (to accommodate the 8M flash and Ethernet PHY) so the next step was to get the Ethernet up. That way I can tftp new boot loader images rather than put up with 2 hour JTAG flash sessions. Actually in hind sight I should have bought a commercial JTAG cable that can flash in 5 seconds. However the Ethernet was dead (no link lights, ping didn’t work), and I didn’t like the look of those complaints about the PHY chip. So I perused the DP83848I PHY chip data sheet. I decided to probe a few pins on the PHY chip with my oscilloscope to see if it looked alive. One pin I tested was the CLK_OUT pin 25, which should have a 25 MHz signal on it. However it was silent. Hmmmm, not good. So I contacted Alen via IM and he confirmed that on other designs using that chip p25 definetely had a 25 MHz signal on it. So I checked the second MP01 I had been sent. No CLK_OUT signal either. When both my MP01’s didn’t have the CLK_OUT signal I suspected it was a wiring/design error. Well, it was just a guess really. Telling these bug hunt stories in review it looks like the outcome was pre-ordained. However at the time you are never really sure. You usually go down many blind alleys, which results in frustration and lack of sleep shutting brain cells down! Anyway clocks should usually come straight up without any software initialization. So I just checked the reset/interrupt lines (in case the chip was being held in the reset state), then I checked the various power supply lines to the chip. A-HA! One power supply line (pin 22 AVDD33) was not connected! Via IM Alen then double checked his other designs and confirmed that yes, it was a bug. When I added a wire to supply 3V3 to pin 22 CLK_OUT came up and the network link light started working. Yayyyyyyy! There is also a golden rule in hardware (and indeed software) development. Anything you change will have bugs. That PHY was changed from the reference design so it’s a natural source of bugs. A bug “emitter” if you like. Then it was time for some network tests. Ping, and even tftp worked. Very cool. The default state of the PHY chip seems to be just enough to get basic network connectivity. This means I can download new RedBoot images quickly as I modify for thew new flash and PHY. It was getting late by this stage so I decided to call it a night. So I emailed Elektra about where we were at and went to watch Top Gear which my three year old. However our story does not end there. Elektra was working hard while I was resting and sleeping. When I woke up this morning she sent me several emails detailing how to set up the RedBoot development environment. This is great – saves me a mornings work. Amazing how working 12 hours apart (Berlin and Adelaide, Australia) can be helpful! Right. Time for some a fresh cup of coffee and some RedBoot hacking.  Hardware for First Mesh Potato Phone Call Yesterday we made the first phone call using the Mesh Potato (MP) Architecture – a very important moment in the life of any telephony project! The Prototype Mesh Potato hardware isn’t available yet, so we connected a DIR-300 router to a FXS Interface PCB. The DIR-300 router is based on the same chip set as the MP (Atheros AR2317) so it’s as close a a real MP as we can get. This gives us a development environment almost identical to the MP which allows us to work on the firmware prior to having the actual MP hardware. This allow for faster development compared to waiting for the prototype MP hardware. When the prototype MP hardware arrives we will have tested firmware to use on the untested prototype MP hardware – greatly reducing the scope for bugs. The firmware consists of several device drivers (8250mp.ko, mp.ko) and an Asterisk Channel Driver (chan_mp). To test we connected a SIP phone to Asterisk running on the DIR-300. Asterisk then routes the call to chan_mp, and via the device drivers to the FXS interface hardware. The audio samples actually flow through the AR2317 RS-232 UART, before being converted to TDM bus samples by a CPLD and Atmega microcontroller. Control and signaling is handled by a SPI port constructed from the AR2317 GPIO lines. After a bit of tweaking the full duplex audio quality sounded just fine, CPU load was less than 1%. This was really just a basic Channel Driver designed to test the most important feature (full duplex audio) first. The next step is to add a bunch of other functionality like dial tone, echo cancellation, ringing and on/off hook detection. We are very happy with this step – it’s a big chunk of firmware written and electronics tested. A couple of months ago, Antoine Van Gelder (pictured below), announced a new project called Afrimesh. Afrimesh is a web-based, mesh network management interface. Having a simple GUI for network management and monitoring is critical for the Village Telco, thus I was overjoyed to find out about Antoine’s work, which is being supported by the Meraka Institute at the CSIR. Originally, we had imagined having a management interface for the Village Telco very similar to the Meraki and/or Open-Mesh network management “dashboards” which are graphically-intuitive and easy for anyone to understand at a glance what is going on in the network. However, Antoine introduced a new twist which opens up interesting possibilities. He has designed the Afrimesh software so that it can run on any OpenWRT-based device. It is written entirely in JavaScript. Actually Afrimesh will run on just about anything but, for me, the interesting new possibility is have a dashboard interface that runs on the mesh devices themselves. I didn’t initially appreciate initially the potential that this opens up.
From self organising data networks to self-organising phone networksSo here is where my minor epiphany came. What is great about mesh networks is that you just plug them in and they work. They self-organise in terms of upstream connectivitity, redundant routing, etc. They are a very, very clever way of quickly establishing a pervasive, reliable IP-based network. With the Mesh Potato, we are trying to leverage the power of mesh networks to set up a phone network. Each Mesh Potato access point will have an RJ11 port, into which an everyday phone can be plugged. However, to use the Mesh Potato, some configuration of the phone network detail is still required. People need to have phone numbers to dial and a phone number themselves that people can call. More than that, people have to have a way of finding out other people’s phone numbers. I began to think of the Mesh Potato in different environments to that which we originally conceived. For instance, would Mesh Potatoes work in an crisis environment where there was a need to set up a instant phone network? Could they be designed to self-configure out of the box as a phone mesh? Conversations with David Rowe and Antoine have encouraged me to think so. Imagine you power up your Mesh Potato and an interactive voice response system says:
This is quite a reasonable scenario. We could set up the Mesh Potatoes to do something like the above and the impact would be that you could unpack a box of 24 Mesh Potatoes, power them up (battery or solar), and within minutes have a working phone network. This would work with or without upstream connectivity. It would mean you could immediately start delivering value with a Village Telco even before you have a server, billing, and upstream connectivity set up. The Afrimesh Potato
I think that having a plug-and-play Mesh Potato that will allow people to start talking with no initial technical configuration would substantially increase the take-up rate of the Mesh Potato. I also think the Afrimesh interface offers opportunities for interesting voice/data/presence/twitter/jabber cross-over innovation on the MPs. Love to hear thoughts from others on this. P.S. For those waiting patiently to hold a Mesh Potato in your hand, David and Elektra are in the final stage of PCB design with Atcom. I don’t have a date but we should have prototypes very shortly.  FXS Interface PCB design In electronic hardware design you can be sure that anything new and untested will have bugs. So I have a habit of building the new part and testing it using known working hardware. The engineering concept is to test and debug the absolute minimum, as bug counts tend to increase exponentially with complexity. With the Mesh Potato the FXS Interface hardware is new. This design connects the router to an analog telephone. So Elektra and I have designed a small PCB to test just that part of the design. Here are some pictures of (i) the small FXS interface PCB design we have designed and (ii) an assembled FXS interface PCB, with a WRT54 for scale. The idea is to connect this PCB to a Nanostation 2 or DIR-300 router and build up the Mesh Potato FXS functionality. We can then incorporate any bug fixes into the Mesh Potato prototype. This strategy is also a time saver – while Atcom are laying out and building the PCB for the Mesh Potato Prototype, we can be using the FXS interface hardware above to develop the Mesh Potato software. That way we reduce the overall length of the project as when the Mesh Potato Prototype arrives we will have tested and debugged firmware to run on it. We have plenty of spare PCBs so if any one would like to build up a FXS interface please let me know.  Assembled FXS Interface A few weeks ago Elektra and I started Phase 2 of the Mesh Potato project. In Phase 2 we are working with Atcom to build the prototype Mesh Potato hardware. The first work package is hardware design. Elektra is working on hardening the various ports of the Mesh Potato against environmental and accidental damage. For example making sure the power port is robust to reverse DC connection, and protecting the Antenna and Ethernet ports from static. She is also taking particular care to ensure that the power supply is as efficient as possible; saving a few watts really matters in solar powered applications. I am working on the FXS interface hardware. The Atheros SoC chips have a lot of functionality, but unfortunately don’t have a Time Division Multiplexed (TDM) bus peripheral which is required to connect to the FXS chipset. The current plan is to make a RS232 serial to TDM adaptor, using some programmable logic. Speech samples will flow through the Atheros SoC RS232 serial port to and from the TDM bus. The software side of the FXS interface involves modifying the serial driver (8250.c in the kernel), to store speech samples in buffers that are then uploaded to user mode for Asterisk. It is important that the interrupt service routine is really fast, so I am bypassing much of the standard serial code and writing a custom ISR. Over the last few weeks I have written the modified driver and tested it using RS232 signals from a PC. This week I have been designing and testing the hardware side of the interface. This involves writing a bunch of Verilog code, then testing it using a PC based simulator. I am using the (open source) Icarus and GTKwave programs to simulate and visualise the waveforms. It’s much easier to test and debug all this complex logic in simulation form before firing up any hardware. Over the last few days I have been testing all this logic using a prototype jig:
Two IP04s are used. IP04s happen to have a Xilinx CPLD chip on board that is suitable for running the FXS Interface logic. So on the LH IP04 I reprogrammed the CPLD with the FXS Interface logic. The right hand IP04 in the picture above is used as “life support” for a FXS module. The FXS module runs as per normal on the IP04 but we tap off the various TDM bus signals we need to drive the CPLD on the IP04 on the left. So to test I can speak into a phone connected to the IP04 and the CPLD does it’s thing with the signals, converting them to and from RS232 serial. So far I have tested both the receive and transmit side of the FXS Interface by connecting the serial signals to a PC. I managed to sample my own voice by capturing the RS232 bytes to a file and playing it back on my PC’s sound card. So far so good. Today I have started connecting the FXS Interface to a Nanostation 2. My first tests crashed the Nanonstation! I guess due to something I changed on the serial driver. So time for some debugging…… Links Verilog Tutorial |
|||||||||||
|
Copyright © 2009 Village Telco - All Rights Reserved |
||||||||||||
