From XinaBox Wiki!
Revision as of 23:21, 9 October 2018 by Bg (talk | contribs) (Speed)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

If you are used to breadboard your design, then using the XinaBox eco-system will be somewhat of a change to the way you work. On this page we will try to outline the differences between traditional breadboarding and using XinaBox. Hopefully you will be able to use that to make a decision whether XinaBox is the solution for you.

If you don't know what the term breadboard and breadboarding covers, please read this WikiPedia article

Also checkout these examples of Breadboarded solutions versus the XinaBox alternative

What is the benefit of breadboarding over XinaBox?

More options

Because breadboarding doesn't offer any standard way of connections, any manufactures electronic component can be used directly in your breadboard design. That gives you more options. If you want to use a specific sensor that is not currently part of the XinaBox eco-system, you might find it easier to breadboard your solution.

Does that mean I can't use non-XinaBox Sensors? Of course you can. There are a number of xChips that caters for that: SXxx/SUxx series of xChips allows you to use analog and digital input from non-XinaBox sensors, but the reason you might find it easier is that with for example Arduino, you can execute an analogRead() and that is supported directly in Arduino, while in XinaBox, you need to install a library for that particular xChip and then issue 1-2 similar command to read the analog value.

There are also the Ixxx series of breadboard interfaces, that allows you to connect a breadboarded solution to the XinaBox eco-system. It allows you to convert SPI and UART into I2C, which is the glue in XinaBox.

And finally there are a number of Output xChips that allows you to control external equipment, such as relays, valves, solenoid, etc.

Except for the IXxx series that is meant for breadboard, all the other external facing xChips are based on screw-terminals, allowing a solid fasting of wires without the need of soldering.

More guidance

In the same breath, because there is so many options with the breadboarded solution, you will also find more examples of how to put your circuit together. So if you for example find an example of code to read an analog sensor, and you feel uncomfortable with changing the code, you might want to follow the breadboarding script, even though it would turn out more complicated than a similar XinaBox solution.

Component Cost

XinaBox comes with a price premium over a traditional breadboard solution. The competition in the breadboard world is fierce with tons of components coming out of Asia to highly reduced price. Whether you buy your components from a local drop-shipper or shop directly from for example Aliexpress, you will find breadboarded components cheaper than XinaBox


Obviously as the breadboarding solution is not a set standard, but just a bunch of loose wires, the interface options are legio. If your solution require a specific comms protocol or industrial interface solution, which is not currently supported by XinaBox, you could be in a situation, where it would be easier to breadboard your solution.

Breadboarding versus XinaBox in Education

On this point educational institutions are divided:

  • If focus is on elementary electronic building, understanding each connection in a circuit, such as Vcc and GND, then breadboarding wins.
  • If the focus is on programming/coding and less on hardware building, then XinaBox wins.

Whether you breadboard or you use XinaBox, the coding effort is the same. Initially you might need to learn about I2C in order to use XinaBox, as this protocol binds together the XinaBox eco-system. But if you use breadboarding, you might initially get away with just reading or writing to the GPIOs using digital or analog commands. On the other hand, that could possible get out of hand when you have to learn about UART, SPI, CAN, 4-20mA, etc, etc., which is converted to I2C in the XinaBox ecosystem.

We find schools- and high-schools prefers XinaBox, as it gives results faster, and the learning can be contained within the XinaBox eco-system. The early years of university want to use breadboarding in order to have the students to learn about passive components, such as inserting a resistor in serial with a LED in order to reduce the power consumption and not burn the LED. With the XinaBox eco-system, those issues never plays a role. An finally the later years in university prefers XinaBox for its advanced digital technology, where the focus is on demonstrating a solution.

Some universities find it difficult to hold on to their electronic engineer freshmen. The freshmen sees white/black-boards full of formulas and theory in the first year and feel despondent over the lack of hands on electronics building. Obviously the argument is that the freshmen need to understand the theory before they can build and understand a circuit, but that doesn't change the fact that the student wonder if he chose the right subject. Many universities are opting for the XinaBox solution as a freshman training tool, allowing the students to have a top-down approach to electronics, and getting faster into coding, which after year one is then augmented with a breadboarded solution teaching hands-on low-level (passive) electronics.

What is the benefit of XinaBox over breadboarding?

Unsurprisingly, on a XinaBox website, you would find many arguments in favour of XinaBox, but also remember XinaBox was developed, because of a lack in the existing market to solve issues, which you below will find arguments for.


The eco-system of XinaBox is digital, all sensors are digital and therefore recalibrated, and the results you get from these sensors are in accurate figures according to their data sheets. In the breadboard world you will typically work with analog sensors, which need to be calibrated. Obviously you can also interface to digital sensors in breadboarded world like in the XinaBox world, but then you don't gain anything specifically from not using XinaBox if it was a digital world you wanted to work with anyhow. And obviously you can connect analog sensors to the XinaBox eco-system (as per above), and they also have to be calibrated, but that is why we focus one digital sensors, and just have screw-terminal xChips for the odd analog sensor.

Power supply

We have done a lot of work to eliminate power issues in building a circuit using XinaBox. There is two angles to this:

Variation of power supply

In most breadboard solution, you will need to find a power supply for your circuit and because there is no standard, most builders gets themselves a lab-power supply with a couple of variable outputs, so they can supply 3.3v and/or 5v and maybe other levels. With XinaBox we try to make sure that there are many option for power supply to fit your solution, without the need for special plugs, crocodile cables, battery holders, etc. So with XinaBox you can get battery power for AA, for CoinCell, for LiPo. You can get more than one solution for some of the battery powers, such as PB04 and PB01 are both AA battery solution, but the PB04 also senses battery level and current drain digitally, allowing you to make a solution, that is power aware. There are cabled power solution for USB (both USB A and USB micro), there is a broad DC power supply up to 24 volt with screw terminals, and reverse polarity protection. And you find more power solution either available or coming soon - all easily clicked into your XinaBox circuit.

Level shifting

Another power problem in the breadboard world is working with various levels of voltage. As an example the Arduino Uno is a 5v circuit with signals being 5v tolerant, while a very famous digital temperature sensor, the BME280, is a 3.3v sensor. In order to connect this sensor to your circuit, you need to level-shift the signal, and if you forget about it, you will burn and waste you temperature sensor. Some component providers add level shifting to their breakout boards, but for a price, quickly eliminating the cost saving of breadboarding. With XinaBox the xChips runs on 3.3v. If any xChip needs another voltage, say 5v or 1.8v then the xChip itself will regulate power and level-shift signals. All our bridges to single board computers do the same, so while no power or level shifting is needed for our Raspberry Pi or Beaglebone Black bridges are needed, it is needed on our 96Boards interface (Dragonboard/Snapdragon). It provides 5v and signals using 1.8v, are levelled/shifted to 3.3v in order to connect any of the xChips to a Dragonboard.


One of the big hassles with breadboarding is that the wires are not necessarily solidly fixed, which means when a wire falls out of the breadboarded solution, it might take you some time to figure out where it has to go back. With xChips, there are two simply rules to follow (see Quick-Start) in order to connect the various xChips, you would not have a problem disconnecting an xChips, just to reconnect it 10 min later. You would not need to go back to diagram to figure where exactly the xChips needs to be connected, any position will work.

Because of this issue, many chooses to keep their breadboard designs intact, and not salvaging components for another project, even though they don't use this circuit anymore. In a XinaBox environment, you wouldn't have a problem lending an xChip to a fellow student, since its no effort to disconnect and reconnect. If you don't want to reuse your non used components as per the breadboarding example, then your cost for your next project will be more expensive, see later about Total Cost of Ownership.


Utility covers the phase of your project where you want to start using the circuit, it can be either in a single use situation, or you want to replicate the project for 10, 100, maybe more places.


Because of the simple ruleset of connecting an XinaBox solution together, it is much easier to replicate a project many times. While you might need an engineer to assemble each breadboard version, you could have entry level students replicating the XinaBox circuit faster, easier and safer.


XinaBox Circuit
A XinaBox assembled circuit is way more rigid than a breadboard solution. We have actually build satellites (3), lifting them to 30km/100000ft with a high-altitude balloon, and then letting them fall without parachute (not intentionally), hitting ground with near terminal velocity, and all 3 were still operating as expected - except some solar panels were broken. (11 other projects on the same flight all ended fatally).

One of the reasons why the XinaBox solution is so rigid, is because of the built-in redundancy. Take a look at the circuit to the right, the 6 xChips are connected together with 7 connectors, but because all connectors provide power and signal, you can remove 2 (not any 2 though) of those 7 connectors, and the circuit will still work. It gets better the larger a circuit you make. Our satellite from before was 3x3 xChips, which comes to 9 xChips and there you need 8 connectors. But in a 3x3 assemble configuration you can connect with 12 connectors, making 4 of them redundant - obviously not any 4, but each xChip has at least one other connection point.

Furthermore, the xChip - most of them - are relative small, making them very rigid, they are difficult to bend, so the copper lanes never snaps. And with the connectors, a shock and vibration protection is built into the circuit. That is why 55 satellite will fly into orbit November 10, 2018 with the Antares rocket on the way to the International Space Station, all with the payload build using XinaBox.


Having a clean XinaBox solution neatly interconnected allows easily integration into boxes or other enclosures. With an easy power solution, it is a almost to easy to build and deploy a large scale solution without the need for full turn-key production of PCBs, assembly and enclosures. Whether you just want one or two solution or a large batch, having a neat, rigid, and professional looking solution beats a breadboarded bird nest, even if the enclosure looks nice.


Clicking an XinaBox solution together, is always faster than putting a breadboard solution together, even if you know your circuit by heart. But speed is many things:

Development speed

Because the hardware is so fast to get correctly put together, you as a developer get to do the coding faster. If you during the coding realise that the chose sensor, say IMU, is not having the right specs, you can easily chose another one and replace it without upsetting your hardware circuit. Because of your variability in choosing digital sensors with XinaBox, you will easy flip between a hardware solutions and a software solutions, when it comes to solve next step in your development.

While the raw component might be cheaper, versus the same component in xChip format, the likelihood of burning a component by feeding in power wrongly is considerably lower with xChips. You might need to order replacement, which will add to the development time.

Assembly speed

This has already been covered, but still - it is fast with XinaBox

Relearning speed

Because the XinaBox eco-system uses the same protocol between all our components, the I2C protocol, once you mastered that, you are good to go with any xChip. We have xChips that uses SPI, such as the LoRa radios, but we convert the SPI protocol to I2C on the xChip, so you will still only need to understand I2C, and not learn how to use SPI. The same goes for other protocols, such as UART. Once you understand the XinaBox eco-system, you will be able to churn out solutions faster and faster. And since we are software agnostic, even MCU/CPU agnostic, you can program our cores, or connect then sensors to a single board computer, such as Raspberry Pi, after you liking. The sensor and the way you interface the sensor and the rest of the XinaBox eco-system stays the same.

Speed to Market

If you add all the above arguments together, you get a lower speed to market. And from an industrial/commercial point of view, that is what counts. It means less engineering cost, prototyping cost, TCO cost (see below), but mostly it means you can keep up with (or ahead) of your competitors, if you can match or exceed an Internet of Things (IoT) solution faster. And you get to keep the Intellectual Property (IP) in house.

Total Cost of Ownership (TCO)

A term used valuing what it actual cost of a solution is. Example: An electric car might cost you more initially, but because an electric car only have 10% moveable parts compared to a fossil fuelled car, the service cost is considerably lower, and because you can generate your own power, with solar, wind or maybe have a agreement with your work to charge it there, the cost of having the car over its life time would be cheaper than the fossil fuelled car, that you got for a discounted price.

With a breadboarded solutions you need other stuff, and while you in the list below will find cost that is not applicable for you, it might be for others. If you already are breadboarding then you have already made this investment, and then there is nothing to save - or is there?

  • When you breadboard a solution, you typically need some passive components, resistors, capacitors, etc. But, because you typically don't know what you need, you will by a kit of resistors, such as E12, E24, E48, E96, or even E192. The same goes for capacitors and various other components. Since no passive components is needed in the XinaBox eco-system, you wouldn't invest here.
  • As mentioned before, most breadboarded solutions doesn't come with a easy power supply, so many will invest in a lab power supply.
  • You wouldn't go down the line with breadboarding without a multi meter.
  • Also as mentioned before, since it takes you that longer time to put a breadboarded solution together, and you need to revisits diagrams if you temporarily remove a component, you tend to keep your breadboard solution together longer than necessary. This means you are not reusing the components for your next project, which will increase the cost of that.
  • In an education setting, you can easily ask students to put together their XinaBox solution and at the end of the class, return the xChips disconnected, allowing the same xChips to be reused in the next class. You would get away with that in a breadboarded class.
  • If you need resistor- and capacitor kits, wires, large power supply, multi meter, etc, you will allocate a workshop space for that. Even if you have that already, it is that opportunity cost of allocating a longterm space for electronic circuit building. If you are a private tinker, you probably will end up in the basement. If you are a learning institution, you have to allocate a classroom as a lab. If you are commercial outfit, you would need to allocate lab space as well. At XinaBox all developer works, where ever they are with a component box, typically called a jewellery box, full of xChips, connectors and one USB cable connected to whatever laptop they working with. That allows them to work at home, on the fly, even sitting on a long haul flight and building solutions. Or just in a nearby coffeeshop.
  • Wasted components is also a factor in breadboarded scenario. If you for get the current limiting resistor in front of the LED or connecting a 3.3v sensor to your 5v Arduino board, you will end up with burned components at a replacement cost. The worst part might not be the replacement cost, but the opportunity cost as you awaiting the replacement to arrive.

Adding all these extra cost together, whether they are actual cost, or just time (opportunity cost), you might consider the Total Cost of Ownership for breadboard solutions, far exceeded the TCO of XinaBox.

Final words

Breadboarding versus XinaBox is mostly a matter of hardware eco-system choices. The software development is still the same. What we have observed with some of our users, is that the hardware is so easy to use and put together, that the usual embedded software development fiddling becomes a hassle to a degree that XinaBox is looking difficult to use. While breadboarding is already a fiddling process so the coding doesn't make it much worse.

The code is the same.
The programming is the same.
The software development is the same.
- its just a quicker/easier hardware development process.