FAQ

Processor:

-MK20DX256VLH7
-Cortex-M4
-Clock speed : 72 MHz
-Overclockable to 96 Mhz

Flash Memory:

-256 Kb (192 Kb available after Aurbee stack)
-192 Mb/sec Bandwidth
-256 bytes Cache
Ram: 64 Kb (52 Kb available after Aurbee stack)

Unlike the stock Arduino, our clone does not use AVR style ISP programming. Rather the K20 processor we use is programmed via EzPort. The programming is done via a dedicated programing board, with its own processor and utilizes the K20 native USB support to initiate the programming sequence. Hence there is no need for FTDI

Power requirements:

-2.8 to 5.7 Volts
-26 mA (at full power)
-10 uA (sleep mode)
-Can be USB powered using USB programming shield

The Aurbee Core board simply exposes pads that can be powered by any source (2.8 to 5.7 volts). The coin cell attachment comes as a shield. It can be USB powered if used with the USB shield, or any custom power source. ( for projects that uses Aurbee in there custom PCB).

Ran into a Kickstarter limitation here, We are shipping from Canada, and don’t have a way to specify country specific shipping costs except home Country. So even though US is just a hour drive south, we have to declare the same shipping rate as the rest of the world. Let us know if you guys have any ideas about this.

Zigbee is a rather vast array of protocols. Under the hood Aurbee, is using a subset of Zigbee standards.

It will be safe to say that Aurbee “Stack” is an implementation of Zigbee. Our goal is to abstract all the Zigbee related stuff and keep the Aurbee programming “style” as close to Stock Arduino programming.

In order to do that we will have to support the Zigbee Light Link standard. And to officially say that Aurbee works with it we will have to join the Zigbee alliance and submit the product for testing. All this is purely a matter of amount of Dollars and time available to us. Unfortunately right now supporting (writing the stack and testing) the Light link std. is not in the scope of the project. But Backers are the king. If we get a dozen backers wanting this, we can get this done.

We have reserved factory time in the first week of Aug. so we should be able to ship up to 1000 units in Sep. 2014. The great thing about having in-house manufacturing is we can put Aurbee assembly at priority anytime we want.

The pinouts are achieved using adapter shields. Right now our priority is to create UNO compatible adapters. We can create others as per demand. Please let us know via KicksStarter comments the adapters you would like

We are working on creating some real life use case videos. Please stay tuned.

We started our Kickstarter campaign once we proved the system design and were completely confident of our ability to deliver as promised. Of course it is still an engineering product and until it’s completely finished and field tested, anything can go wrong. That’s why we still consider us at “prototyping” and not “ready to ship” stage.

We are asking for your support to get us from the “prototyping” to the “ready to ship” stage.

As an Example we recently had www.jamiemcshan.com ask us this question for when he would use Aurbee for is R2D2 model ( I know awesome right)

Here was our response :
We had a customer ask us a question like this for his model R2D2 ( I know awesome ) and here is our response :

Latency is a combination of various factors including

• The processor load on the Aurbee devices (if the devices is doing a complicated MATH algo while sending out information)
• The distance between the Aurbee devices
• If the Sender and receiver are in direct radio contact or need the data to be “routed” thru another Aurbee in the network.

• 1. Let’s Start with a simple solution
  • There is One Aurbee (with 3 input buttons, and 2 analog inputs for the Joystick) acting as the stealth remote. It is not doing any other processing except monitoring button presses, joystick movement and let’s say flashing few local LEDs
  • There is One Aurbee (sitting inside R2D2) with 3 PWM outputs to Motor controllers and few digital Outputs for MP3 payers, leds and what not
  • The stealth remote, and R2D2 are within 50 feet of each other and there is not crazy radio interference going on. (Example no one is testing a Tesla arch) In this situation the Latency will be in the in few millisec range. My test boards I get latency from 2 to 10 ms

 

• 2. Let’s complicate the situation, add radio Interference or increase the distance to 80 feet. Where the Aurbee’s can still communicate directly but need to compensate for lost packets. You can have latency of upto 50 ms. (over 50ms) Aurbee will consider the other Aurbee out of reach and attempt to route it thru an intermediate devices.

 

• 3. Even more complicated, the remote and R2D2 are over 100 feet away and you set up another Aurbee Somewhere in the middle ( say on a camera tripod or something) in the Middle. The first time you try to communicate, it can take upto 5 sec for the Aurbees’ to time out and “Self-Heal” to discover the new route that the Stealth remote data needs to be routed “thru the intermediate Aurbee” to R2D2 . Once the Routing has been “automatically” established you can expect latency of 4 to 20 ms. Of course if the R2D2 is moving and needs another routing change, there might be another “self-healing” time.

Please note that in this case we are completely relying on the Stock Aurbee “self-healing” routing without any custom parameters.

If you are in a big convention and you want R2D2/Stealth remote to cover a 300 feet by 300 feet room and both constantly moving, you can set up the “intermediate Aurbees” in strategic locations, and pre-configure the “routings” to make sure there are never any “self-Healing” drops and keep the max latency in the 20 ms range.