PR1-Appliance
January 13th, 2008 by 
mark
The PR1-Appliance project is maturing quickly and we feel that it’s time to share with you it’s progress.
At first, let me remind you that PR1-Appliance is a first of it’s kind, Blackfin driven Asterisk based T1/E1 PRI appliance. The schematic is distributed under a disjunctive tri-license giving you the choice of one of the three following sets of free software/open source licensing terms:
* Mozilla Public License, version 1.1 or later
* GNU General Public License, version 2.0 or later
* GNU Lesser General Public License, version 2.1 or later
The software, Astfin2 is available under GNU General Public License, version 2.0 or later.
Specification
Since, all main subsystems with the exception of the framer are almost identical to BR4 we were able to bring them up very quickly. Thanks to ADI, we were fortunate to use few pre-production units of BF537 silicon rev. 1.0.3. That eliminated problems related to silicon anomaly #05000263 limiting uClinux kernel to access only 43MB of SDRAM and anomaly #05000305 ; Additional Hysteresis on SPORT Input Pins.
Since, I had to make only few modification to uBoot and uClinux to support 600MHz/120MHz core/bus plus 128MB of SDRAM, the board was up and running within 30 mins. No more trills related to Blackfin based boards 
They just work and work as expected.
The PR1-Appliance is amazingly fast, 600MHz CPU makes a difference. The most significant visible improvement over BF532 based boards is on the Ethernet side. Due to high performance PHY and BF537’s option to use L1 cache with Ethernet , tftp download speed is several times faster than on bf532 based products.
At this point we already have a very fast and small development board…sweet :), but I want to see Infineon chip in action
I logged in and connected to asterisk (asterisk -vvvvrc) to see if pri/zap are loaded. Well, since everything is going so smooth a little bit of optimism is expected…
Bummer! No pri commands and no zap loaded. I need to check my config files…
Well, zaptel was not loading since we had zap channels defined but not present. libpri was not loading due to dependency problem (it wasn’t compiling). I was able to quickly correct these problems and move forward. At this point I could properly read the Chip Version (FALC chip ID), but I could not initialize the sport properly. After checking the driver code I realized that we were using SPORT0 definitions for BF532/3. We need to use different DMA channels for Sport0 on BF537 so small code modification was required. Pawel offered his help and while I was looking at SD/MMC support he quickly added sport0/BF537 to wpr1.c/h. We got full E1 span up on the first boot. The box was already connected to our digital test bench and configured to derive clock (slave mode) from our “CO”.
Just few minutes later we were making calls between Aurora-Sonata, PC based Asterisk and PR1-Appliance.
Over the next few days we conducted various tests to confirm proper functionality and reliability under full load.
I will let Pawel talk about the results as he designed and managed our test procedures.
In the meantime you can review schematics for PR1-Appliance
Cheers,
Mark
January 16th, 2008 at 7:11 pm
That is a handsome looking product there guys, and it is wonderful to see a free (as in speech) reference design for an embedded Primary Rate IP-PBX.
How would you compare the PRI Appliance to an x86 PC based solution (say a commodity PC with a PCI PRI card)?
Cheers,
David
January 16th, 2008 at 8:20 pm
David,
Thank you for your kindness.
TO answer your question, well, it all depends
Our solution is very price competitive (appx 400 Euro) and physically very small. On the other hand, we do not have extra “horse power” available to 3rd party applications.
We provide a small, inexpensive and yet very focused and reliable platform integrating digital telephone network and VoIP all together.
With the PC based solution one would need to purchase a card and a PC. This would cost much more… and it would take much more space and … energy.
There is also another benefit; OEM opportunity; companies could use our hardware/software to jump start their own creation and get to the market much quicker with their own product running on their own black box. The perceived value (”IP”) would be much higher than running the same product on the traditional PC.
Cheers,
Mark
January 16th, 2008 at 8:26 pm
Hi,
Compatible for Basic rate interface (BRI, 2B+D, 2B1D)? because my country Telco is not available for support with PRI ( Interface).
Or enable to change (update) into Basic rate interface (BRI, 2B+D, 2B1D) device by users ?
Thank And Best Rgds
Jason
January 16th, 2008 at 8:33 pm
Mark,
Another question :
It works with IP04 PBX with E1/T1 30/23 Channels beside Asterisk PBX? Basically it will be done, but you have verified with IP04 PBX.
Rgds
Jason
January 16th, 2008 at 9:53 pm
Jason,
Please see our BR4-Appliance for BRI type interfaces. Very similar features, just BRI instead of PRI
I am not sure what do you mean by “verifying if it will work with IP04…”
Cheers,
Mark.
January 17th, 2008 at 3:54 pm
Mark,
Excellant Work. The PR1 Applicance looks like a really nice peice of gear.
How is the hardware Echo Canceller coming? I can’t wait to see how that does!
Bill
January 17th, 2008 at 8:53 pm
Bill,
The e/c modules are coming….
As usual..stay tuned
Cheers,
Mark
January 18th, 2008 at 4:32 am
Is anyone selling these (BR4 and PR1), preferrably in a ucpbx.com way?
January 18th, 2008 at 7:29 am
Faidon,
Both products will be available shortly through the ucpbx store (and other online shops).
The first production quality BR4s should be available by mid March.
The PR1 should be available sooner. The beta units will (probably) be available before.
Cheers,
Mark
January 30th, 2008 at 12:04 pm
Hi Mark,
My question might look a little bit odd but you think there would be a possibility of implementing SS7 protocol on such a device, I think it would be possible to shape a SS7 gateway with such a device, at least for doing mtp2 layer. I’m so eager to talk about it with you and have your ideas. And as another non sense question, you think we could replace the FALC56 with a MUNICH32 (32 HDLC channel) chip to over come some protocol stack implementation with?
I know its odd but who knows may be possible.
Regards.
January 30th, 2008 at 2:44 pm
Hi,
I am not sure how big is the market for SS7 gateway with only a single E1 span. Also, which SS7 stack do you have in mind?
On the hardware side; Yes, we could change the framer. Please contact me directly to discuss.
Cheers,
Mark
March 7th, 2008 at 6:41 pm
Yes, it is possible to implement MTP2 on this box and use it as an line interface where MTP3 and the rest of SS7 w/Applications run’s on a server.
Not only is it possible, but a very modular and strong architecture.
You can build up a very scalable system this way.
March 21st, 2008 at 3:15 am
Hi Jan,
BINGO. The ultimate solution would be that you told but i doubt how many signalling links such a CPU could handle. Im getting a sample board to start my work on, lets see what is the results.
April 27th, 2008 at 12:23 pm
A Blackfin can handle more than you think, keep in mind that each signaling link means one channel only doing HDLC - nothing else!
The rest of the stack is not really real-time.
Also, how many links do you need?
1 link which is already in the Falc56 is probably sufficient for a majority of actual C7 deployments.
Yes, 31 links would be a nice feature, but except for high end IN’s there would be limited usage.
—-
May 6th, 2008 at 9:43 am
Where can I get a sample of PR1?
Thank you!
May 7th, 2008 at 6:30 am
Ernest,
Please contact me directly via email
Mark