In order to perform standard actions such as collect data (current consumption) or turning on/off some appliances, the modules (ZB01) will communicate with 3rd party ZigBee sensors and endpoints.
In addition, we will provide speciality ZigBee endpoints which could monitor and collect data for medical applications and/or from other non telephone/home automation areas.

ZB01 Coordinator modules

In the near future, we will also provide a standalone ZigBee coordinator with UMTS and Wifi support for seamless integration into the Wireless world.
In addition to ZigBee, we will soon announce new modules providing support for PTT or 4wire interface. This will simplify integration of IP0x/FX0x devices with Two Way radios and similar devices.

Stay tuned …

Tinyworx, a Toronto-based startup, is pleased to announce the RP08 – a new Blackfin-based appliance available as of January 2010.

RP08 is a versatile dual-cpu router/pbx system, with the following specs:

Router
Micrel KS8695P SOC
- OS: Linux kernel 2.6.32
- ARM 922 Core running at 166MHz
- on-chip 8K instruction cache and 8K data cache
- on-chip XceleRouter with 1 WAN + 4 LAN port switch
- external Mini-PCI interface implemented to support the EnGenius EMP9602 Wireless Card (Atheros AR9160 + AR 9103) 802.11/n
- 8MByte FLASH
- 32 or 56 (RP08+) MByte SDRAM

PBX
ADSPBF537 @ 600 MHz
- Astfin 2.1
- 4MByte FLASH
- 64 or 128 (RP08+) MByte SDRAM
- one SD-FLASH card slot (linux root filesystem, voicemail files, etc…) – tested with 4GB SD card.
- on-chip 10/100 MAC with external PHY directly coupled to LAN1 connection of router
- on-board 10/100 MAC/PHY – WAN dedicated for voice traffic, could also be used as failover WAN for data traffic
- on-board battery backed-up RTC
- 8 port analog interface

Analog Modules:
- Single port FXS (available)
- Single port FXO (available)
- 2-Way Radio interface (available in February – it can also be used for external paging or audio input)
- GSM, g729/echo cancellation modules scheduled for late Q1/early Q2, 2010

Other plugin modules:
- EnGenius EMP9602 Wireless Card (Atheros AR9160 + AR 9103) 802.11/n
- USB interface, configurable to run on either KS8695P or BF537 cpu (available in February)

External ports:
- 1 Router WAN (RJ45)
- 1 PBX WAN (RJ45)
- 3 Router LAN (RJ45)
- 8 Analog Ports (RJ11), pins 4-5-6 on port 1 and 8 can be configured via jumpers as KS8695P/BF537 console output
- 1 USB (type A)
- 1 USB (type B)

Internal connectors:
- 16 bit external memory interface to both CPUs (currently used for the USB module)
- mini-PCI (currently used for WiFi module on the KS8695 cpu)

Power requirements: 7.5 V, 1.5A DC

External Dimensions: 6.2 x 9.1 x 1.5 in
PCB Dimensions: 5.7 x 8.6 in

Tinyworx

Website: www.tinyworx.com
Technical Inquiries: James Mitchell , (416) 642 6050 x. 202
General Inquiries: contact@tinyworx.com
Phone Number: ++1 (416) 642 6050

RP08 Appliance USD $450
RP08+ Appliance (double RAM size) USD $500

Single Port FXS Module USD $35
Single Port FXO Module USD $35
WiFi Expansion Kit
EnGenius EMP9602 card + 3 antennas USD $75

The Asterisk GUI included in Astfin 2.1 is updated. The most important new features are

• Reset Configuration button in the Option page

• Version of the firmware can be check in the System Info page

This is just a beginning of a serial of GUI updates we plan to implement in the near future.
The code you can find in our SVN repository.

Stay tuned
Dimitar

It is now very simple to upgrade your Astfin firmware (both u-boot and uClinux). The update is working from u-boot and require internet connectivity of course. As soon as you start the procedure your board will check the latest available version of the firmware for your board, will download it using tftp protocol and will save it in the non-volatile memory of your board.

To start the procedure you need a console access to your board. Interrupt Linux auto-booting and type in u-boot prompt

run upgrade

You will get the information about the upgrading process.
Keep in mind that this new feature is introduced in our latest u-boot and you will have to update your u-boot manually in order to use it.

Comments invited
Dimitar Penev

Let me put a short introduction about the different flash based file systems.
This will explain why we have decided to migrate Astfin 2.1 to ubifs

Few years ago there was two popular flash based file systems, jffs2 and yaffs2.
jffs2 (Journalling Flash File System) is actually the dinosaurs of the flash based file systems with lot of nice features like, compression support, power-down resistant, wear-leveling. It was designed however some time in the past and it is intended mostly for small partitions (<10MiB). As a result for bigger flash memories it takes very long time to mount the partition and it uses lot of RAM.

The alternative was yaffs2 (Yet Another Flash File System). yaffs2 supports everything what jffs2 supports except the compression. In addition yaffs2 is smarter, developed for bigger flashes in mind. It mounts the partitions much quicker than jffs2, and it has better read/write speed. In addition it takes less RAM. Taking those features in mind it is clear why few years ago people started to migrate from jffs2 to yaffs2, especially for the situations when compression is not needed like storage of already compressed data (zip, tgz, mp3 etc)

However nothing is ever perfect. yaffs is not perfect as well. The main problem except the lack of compression is something experts call partition scalability.
With other words, what happens with the speed, RAM consumption, CPU usage of the file system when the size of the partition increases. Both jffs2 and yaffs2 scale linear versus size of the partition which makes them not very good for partitions above 100MiB. So it didn’t take long time and we saw new players. Most popular are LogFS and ubifs.

LogFS working directly on top of MTD devices and is meant to replace jffs2 as it is well scalable for big partitions. It adds some nice features to the file system portfolio (like snapshots for example) but it seems still work in progress.

The new generation flash file system, containing all of the features mentioned above including compression is ubifs
ubifs is scalable in terms of partition size. It has neat journal and fast garbage collector.
In addition ubifs can postpone writing to the flash chip (write-back caching) which can speed up file system operations dramatically in some cases. ubifs is not working directly on top of the MTD devices. It needs an extra UBI (Unsorted Block Images) layer which in its core does a mapping between the logical blocks (which are used by ubifs) and the physical erase block on the flash chip.
Splitting the file system in two layers helps the developers to divide the complex task in to simpler subtasks
ubifs is already in the Linux mainstream which makes it very easy for adoption

In order to use ubifs first we need ubi device. Fortunately there is an users space tool for it.
To create ubi0 device on top of mtd3 flash you can do
ubiattach /dev/ubi_ctrl –mtdn=3 –devn=0
You need ubi_ctrl node on your devfs with major 10 and minor 63.

First time you use ubi0 you need to make a volume on top of it. To create 900MiB volume with name test you can do
ubimkvol /dev/ubi0 -s 900MiB -N test
You need an ubi0 node with major 253 and minor 0 to perform this step.

Finally you can mount directory /ubifs_test using ubifs like this
mount -t ubifs ubi0 /ubifs_test

Have fun
Dimitar Penev

In addition it can simplify the network configuration in case the PBX is behind symmetric or asymmetric NAT.

 
To confirm the basic functionality I have done a simple test. Let me describe it here.

For establishing of the simplest possible VPN tunnel apart of the two communicating Edge Nodes one extra Super Node is needed.

Initial tests was done using three BR4-Appliances manufactured by uCpbx Ltd . An example is shown below. The prompts of the BR4-Appliane devices was annotated so it is clear where the specific command is executed.

Let’s start the Supernode service on one of the BR4-Appliance. The IP of this Appliance is 192.168.1.99 and the Supernode service is listening on TCP/UDP port 20. For this simple test all of the Appliances are in the local network. In reality Edge Nodes should have connectivity to the listening port of the Supernode

root@br4_supernode:~> supernode -l 20
06/Sep/2009 11:33:15 [supernode.c: 477] Supernode ready: listening on port 20 [TCP/UDP]

Let’s start creating the VPN network.

root@br4_edgenode1:~> edge -a 10.1.2.1 -c mynetwork -k encryptme -l 192.168.1.99:20 &
06/Sep/2009 07:35:20 [ edge.c:1138] Using supernode 192.168.1.99:20
06/Sep/2009 07:35:20 [tuntap_linux.c: 38] Interface edge0 has MAC 66:D7:A3:3E:BE:94
06/Sep/2009 07:35:20 [ edge.c: 670] Registering with supernode
06/Sep/2009 07:35:20 [ edge.c:1370]
06/Sep/2009 07:35:20 [ edge.c:1371] Ready
06/Sep/2009 07:35:20 [ edge.c:1037] Received REGISTER_ACK from remote peer [ip=192.168.1.99:20]
06/Sep/2009 07:35:20 [ edge.c:1437] STATUS: pending=0, operational=0

In the edge command above mynetwork is the name of the created VPN nethwork and encryptme is the encryption key associated with this Edge Node.

New virtual Ethernet interface edge0 is created.

root@br4_edgenode1:~> ifconfig
edge0 Link encap:Ethernet HWaddr 5A:9C:0C:2B:ED:08
inet addr:10.1.2.1 Bcast:10.1.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500

eth0 Link encap:Ethernet HWaddr 00:09:45:56:21:A0
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:86 errors:0 dropped:0 overruns:0 frame:0
TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0

Lets do the same for the second Edge Node but this time will give different VPN IP address 10.1.2.2
root@br4_edgenode2:~> edge -a 10.1.2.2 -c mynetwork -k encryptme -l 192.168.1.99:20 &

Now we can ping one of the Edge Node from the other through the new VPN tunnel, and vice versa.

root@br4_edgenode1:~> ping 10.1.2.2
PING 10.1.2.2 (10.1.2.2): 56 data bytes
64 bytes from 10.1.2.2: seq=0 ttl=64 time=3.237 ms
64 bytes from 10.1.2.2: seq=1 ttl=64 time=3.010 ms
64 bytes from 10.1.2.2: seq=2 ttl=64 time=2.980 ms
…

root@br4_edgenode2:~> ping 10.1.2.1
PING 10.1.2.2 (10.1.2.1): 56 data bytes
64 bytes from 10.1.2.1: seq=0 ttl=64 time=3.237 ms
64 bytes from 10.1.2.1: seq=1 ttl=64 time=3.010 ms
…

The new package can be used for easy creation of a secure voice channels.
For more information about the actual VPN implementation please take a look at n2n

Dimitar Penev

Inoteska-1

Full Press Release

Hardware

BLACKFIN processor BF527 600MHz
64MB RAM
128MB NAND Flash
8MB DATA Flash
Optional SD card
Power supply: 230V/50Hz or DC 48V
Dimensions: 160x233x27mm (heigth depends on used modules)

Interfaces

A variant (backplane) – 8 analog modules
0/32 analog interfaces
0/6 E&M interfaces
0/4 BRI interfaces S0 TE/NT with optional power supply 48V
1xE1 (future expansion possibility up to 2,3 + HW Echo Canceller, if without BRI)
1xUSB OTG
2xEthernet 10/100BT
1xRS232 console
0/4 GSM (future expansion up to 12)

B variant (backplane + extension board) – 16 analog modules
0/64 analog interfaces
0/12 E&M interfaces
0/8 BRI interfaces S0 TE/NT with optional power supply 48V
1xE1 (future expansion possibility up to 2,3 + HW Echo Canceller, if max 4xBRI)
1xUSB OTG
2xEthernet 10/100BT
1xRS232 console
0/4 GSM (future expansion up to 12)

The schematic is available as well

br4-appliance

After seeing tremendous success of IP04 and IP08 units designed by David Rowe and manufactured by Atcom, we’ve decided to accept Atcom’s offer and to utilize their manufacturing capabilities to deliver our BR4-Appliance to the market in production quantities.
As a result…first units are already being distributed to our initial customers.

The BR4-Appliance (or IP-BRI ) as all other our designs runs Astfin2, which is in essence custom uClinux distribution oriented towards telephony applications.
To provide ISDN connectivity we run mISDN stack and chan_misdn to communicate with Asterisk

For Web based management, we provide slightly modified version of Asterisk GUI 2, with support for our digital line interfaces and other BR4-Appliance specifics.

In order to provide Telco grade quality, we’ve developed hardware based Line Echo Cancellation module which is distributed as an option for the BR4-Appliance.

BR4-appliance can be purchased from uCpbx Ltd. or Atcom

Specifics:
Hardware:

ADSP-BF537 600MHz CPU
64MB SDRAM
256KB serial flash for the bootloader
256MB NAND flash for voicemail and prompts.
SD card interface on a dedicated bus
Hardware G.168 Line Echo Cancellation (64 ms) (optional)
Power supply 6 - 12VDC
Power consumption; idle state; 150 mA at 12V?

Interfaces:

Quad ISDN (2B+1D) interface
TE with PTP and PTMP
EuroISDN (mISDN)
Single 10/100 Mbps Ethernet port with high performance PHY
RS-232 interface for console access

Target Markets:

VoIP - TDM Gateways
PBX / IVR / Call Centers
VoIP Services
Conferencing
Custom Platforms / Development

How do I purchase it?

For all our products, including IP-BRI (BR4-Appliance) and optional echo module, please visit our online store at uCpbx.com

Whats’s Next ?

We are already working on the 2 port version with NT/TE support and a smaller footprint

Enjoy,
Mark

As you probably know we already have built “Hardware based” echo cancellation module based on Zarlink ASIC and we are very satisfied from its performance. The main characteristic of the “Hardware” echo cancellers is that they just work.  I was not felling very well however due to  the fact the algorithm is deeply buried in the silicon  After all I have my background in the DSP field.  You probably will recall that a few months ago I have done a study on the open Line Echo Canceller from MIKET DSP Solutions.  Thank you “MIKET DSP Solutions” for providing this code! The results of the cycle true simulation was very promising and we decided to build our own TMS320VC5510A based echo canceller module.  Well the PCB is designed and we are expecting the first prototypes ready very soon. PCB is shown below.Pin headers of this module is compatible with our ISDN PBXs

I am eager to hear Mike’s echo canceller on the real DSP hardware

Dmitar

Specification
1. ADSP-BF533 500MHz CPU
2. Onboard 128MB SDRAM @ 125MHz
3. 256KB serial flash for the Bootloader
4. 2 Ethernet ports
5. SD/MMC card interface
6. 512MB NAND flash for voicemail, CDR and prompts.
7. Buffered clocks and TDM bus
8. Up to 8 Analog FXS/FXO modules
9. Support for optional single span E1/T1 module
10. Astfin2 with Asterisk 1.4.x, Zaptel 1.4.x
11. 4 layer PCB
12. System LED blink during boot process
13. Hardware reset to factory defaults
14. Battery backup for Real Time Clock