Ground Penetration Radar with LIME2 the ultimate tool for all treasure hunters

Screenshot from 2017-04-04 11-45-57

Ground penetration radar is cool device which allows you to see what is below earth surface. The principle is same as the radars which operates at air. They send pulses and sense the reflections of this pulses back. When the surface is not consistent you get reflections which allow you to “see” cavities of metals under the surface, some GPRs can scan as deep as hundred meters below the surface. This is ultimate tool for all treasure hunters, but also very useful if you want to see water and other fluids underground.

We spotted interesting post at our forum for GPR made by company from Plovdiv with LIME2.

The device looks very nice in the custom box they made:

7-small

The GPR has antenna and WIFi connection so you can connect and visualize the results with any device:

10-small

 

FOSDEM and TERES I update

fosdem-1

FOSDEM was great place to present the TERES I, as there were the right people who share open source values.

We got lot of people passing through our table and got tons of feedback and suggestions. Thanks guys!

One of the most asked questions was: “can you make it with more RAM memory?”  The answer is yes, we can and we even have the memory chips which easily allow TERES I to be with 2GB RAM, but these are quite expensive than the mainstream memories as they are just two 4Gb memory chips put in one package with two Chip Select signals which A64 supports. As these memories are not so used their prices is more than double of the normal DDR memory price and this is why we though initially that this will be expensive option to consider. If we put 8Gb DDR memories on TERES I instead of 4Gb and make the RAM memory 2GB this will affect the price with EUR 15. Perhaps we should just add this as option when we assembly the main boards and people can decide what to buy 1GB or 2GB RAM version.

The 4GB mainboard eMMC flash is also quite humble for storage. Micron who manufacture this eMMC has also 16GB and 32GB versions, but they are very slow to deal with, just to receive quotation from their sale reps here needs weeks and even if you order they will tell you something like 20-30 weeks delivery time. For the moment this is no go. We use these 4GB eMMC in our other boards this is why we decided to use here too. The 4GB eMMC is in stock and we can produce right now. The micro SD card connector kinda solves the storage issue as you can use up to 128GB micro SD cards, but they are not so fast as the eMMC on board. Anyway if we could make deal with Micron later we could offer mainboards with more on board eMMC.

Another interesting suggestion was to add small SPI flash on the mother board. Initially as hardware guys we decided to not do this when we designed the main board. our though was: if you have eMMC 4GB on board which you can read with 100MB/s and write with 10MB/s why would you need slow serial SPI flash with small capacity like 4MB on board? We got explanation at FOSDEM why some people would love to have it. The SPI Flash could be used to have boot code from which A64 will always boot first. The SPI Flash could be hardware write protected, i.e. you will be always sure that your processor boots trusted software and no one could overwrite it except if he has physical access to your laptop and open the plastic and put the SPI to read/write mode again. The mainboard eMMC could be overwritten from user space, so considered as compromised media for secure boot by the people who care about their security.

One more good feedback was that A64 has OTP bits, one of which once set A64 will refuse to boot unsigned code, and no one knows how to sign code for A64 yet, so this effectively bricks your device and all existing A64 boards and tablets and laptops suffer from this problem. One could now write malicious software which to set this OTP bit and brick the A64 devices on the market. Fortunately there is A64 pin which enables and diables the OTP writting at hardware level, so we are going to disable OTP write by hardware.

Another question was “can I have better display with higher resolution?” Sure you can! TERES1 laptop has eDP interface which all laptop LCDs share, so any LCD with eDP interface will work, and of course will require proper Linux setting. Right now if you do not like the current 1366×768 resolution you can search for other 11.6″ with eDP connector and spend almost as the cost of the TERES I for LCD with IPS and 2K or 3K resolution, but franky we do not see the point of fancy graphics as TERES I would never be laptop for graphics developers anyway.

Other  people were asking: “can I have 16GB of RAM, SSD disk” No, unfortunately this is not possible. A64 is humble low cost processor, it has no SATA, so SSDs are not possible to connect except via USB which spoils the SATA speed. And IIRC 4GB RAM is the max A64 can address, but needs total mainboard rerouting. At this stage TERES1 would never be developer laptop which you can use to build Linux kernels, or do fancy graphics etc. We see it more like hacker tool. We made it lightweight, our target is to run on battery for long time, so you can get it while you travel. We work on FPGA internal board which you will be able to program with FOSS and to add Oscilloscope and Logic Analyzer capability at later stage while keeping all other hardware intact so it will be add-on board. We think of TERES1 as to become portable lab for hackers, to may program Arduino boards, sniff protocols at hardware level, capture analogue signals etc. it will be still good to browse internet, edit text files, code embedded software, but do not expect it to replace your desktop.

Good suggestion was to bring out the debug UART console so developer could see kernel messages without opening the laptop and solder wires. So we decided to add multiplexer and will bring Serial UART TX, RX, GND on the audio headphone jack which will be multiplexed by software, so the developers could just plug serial cable to Audio jack and debug.

Some people suggested us to place Arduino connectors near the touchpad where you add Arduino shields, this need a bit of consideration. When you do prototype work and experiments there is always possibility to damage your hardware, even now when we use Arduino we always put USB-ISO between it and the computer we use to program. With this protection we are sure that if we short something or feed high voltage to the shield by accident we will not damage our computer. So this is great idea but needs a bit of thinking.

Some people were asking: “do you think if this will be commercial success project, your laptop is so expensive, there are Chinese laptops for $50, $60, $100?”

Frankly we do not care too much about this, our core business is development boards and if you follow our blog you see that we have enough work. We spend more than year on TERES I so far and it was fun project and we learned a lot during the development. Now if it will be liked by many people or not is not so important, the important thing is that we made first step to bring to people, who appreciate open source an platform and template which they can use and improve both harware and software wise.

This is why we selected KiCAD as our CAD for designing TERES I. What is the point to release OSHW made with Altium or Eagle which will require your community to spend thousands of EUROs if want to study or modify your files? Every time you use proprietary tool to make Open Source you just decrease your community base just to people who can afford to buy the tools you used to design.

Now TERES I gives freedom to everyone to download KiCAD,  the CAD files from GitHub and people can view how it’s done, learn something new, and if you do not like something you can modify it up to your taste. You can’t do with any other laptop on the market.

Note that this is just the first step, the development and the fun will continue. Once we finish the software, add on boards we will look around for more new SOC candidates as well.

Not at least everyone was asking “when it will be available for sale?”. We build our first three prototypes 3 days before FOSDEM. While we worked more than year on the harware and we solved all issues there, the software is in quite initial state.

For the moment the only working Linux Kernel which supports all A64 features is the Allwinner Android Kernel. This Kernel is full of binary blobs, but the only one which could be used for demo. Beside the binary blobs many other things are broken, like the power management, different drivers like the LCD backlight PWM, wake up from suspend, eDP converter is not set properly and works just in 15 bit color mode etc etc. We have the hardware for 50 laptops ready (developer edition), but we do not want to ship before we take care for the software. At other hand we do not want to ship TERES I with Android or RemixOS also which are complete with binary blobs and will never be Open Source.

So let’s hope we will have good enough Linux support in couple of months and we can start the shipments, until then please wait patiently, we spend over an year and now we are close to the final 🙂

All above suggestions requiring the hardware modifications for the debug console, OTP lock, SPI Flash will be implemented in the next run when the software is completed.

 

A20-OLinuXino-LIME2 now with PCB revision G

a20-olinuxino-lime2

A20-OLinuXino-LIME2 now is assembling on same PCB Revision G as A20-OLinuXino-LIME2-eMMC.

What are the improvement:

  • Ethernet PHY is changed to RTL8211E replacing the obsolete RTL8211CL no need for kernel patches;
  • we drop the odd shape which was necessary to fit LIME2 in the plastic box as we now have range of metal boxes;
  • the four mount holes now have grounding for better contact with chassis;

Meantime we silently work on further improvement for next revision (to be released March 2017):

  • adding SPI boot Flash;
  • replacing RTL8211E to industrial grade PHY, so the board can be produced completely in -40+85C operating temperature;

 

Pre-Christmas Crazy times – Expansion of production capacity with three new Samsung machines

christmas-balls1

Probably many of you wonder why we are so silent recent months and nothing new is posting on the blog. The reason is quite casual – we are overwhelmed with work!

Starting from September something odd happens. Our OLinuXino customers went in crazy mode and we start getting almost twice more orders than usual. All who have been dealing with production know that to double capacity needs time.

This is the reason for the delay with iCE40HX8K-EVB, A64-OLinuXino, TERES release – there is simple no free window on the SMT assembly machines and testers to may run them, the machines are busy with OLinuXino and SOM assembly.

The small orders are shipping on time i.e. in 1-3 working days, but all bigger OLinuXino and SOM orders for 50+ boards are now shipped with a bit of delay as we have quite backlog for these boards.

We apologize to all our established customers which do wonder why the orders which we usually shipped to them in 1 week before, now are shipped with delay of 3-4 weeks.

We assure you that we do everything humanly possible to ship all orders ASAP.

To add little more crazyness the three new Samsung machines arrived two weeks ago. We wanted to build new space for them and working more than year on this, but the lazy and ignorant Bulgarian administration still didn’t issued us permit to start building, so we have to install them in the old building where we run out of space.

20161118_102525

20161118_102818

One SM471 and  two SM482 with printers, loaders, unloaders, conveyors, packed in 20 wooden boxes were unloaded from the containers:

20161118_102435

Immediately we start to break walls, extend doors, and other funny things so the big machines may enter the building.

20161126_085319

20161126_085332

20161127_075039

We did same 1 year ago when our first Samsung came, but shortsighted decided to rebuild the walls with intention the new machines to be installed in the new building, without taking into account how long and difficult the building permit is to get in Bulgaria.

Now the three machines are installed and testing, but as you guess they will not run alone, so we will need new employees to train.

New Year – new luck we say here, I hope things will go back from crazy to normal mode in January!

EDIT:

Some words about the machines SM471 is the Samsung fastest and greatest from SM series. It has two heads with 10 nozzles each and dual rail conveyor which allow two different boards to be assembled at same time. With maximal performance 75000 csp (which you never reach on real boards). The machine can place down to 01005 components which are with size 0.4 x 0.2 mm (400 x 200 microns)!

SM482 is flexible mounter which can place both small and big components, we already have one such machine and it performs very well. The listed maximal speed is 28000 cps.

Each SM482 machine comes with full set of 8, 12, 16, 24, 32 mm feeders and tray changer which can hold up to 80 trays with components.

Both SM471 and SM482 support the new splice-less tape feeders which can be load even with component stripes without need to have initial empty cells on the tapes.

A20-OLinuXino-MICRO works hard inside Open Source Rover Octanis project in freezing Antarctica!

r3

One year ago we got request for sponsoring 5 pcs A20-OLinuXino-MICRO for Octanis project from group of students at EPFL, who are making an open source rover (http://octanis.org/rover) that will go to Antarctica.

Their goal was to use A20-OlinuXino-MICRO as a communications base station with LoRaWAN and to use it for onboard image processing of their stereoscopic camera images.

r1

Needless to say the magic words “open source rover project” closed the deal 🙂 We shipped the boards in December 2015 and yesterday got e-mail that the rover operates since February 2016, but he was moved to Antarctica in November and will stay there till February 2017.

r2

You can track the rover position right now at http://octanis.org/constellation/

asumablog

On GitHub you can see their 3D parts CAD files and all firmware running on the rover. You can reproduce this project with 3D printer.

 

 

 

Final updates on A64-OLinuXino GMAC and eMMC, we are ready to launch production

A64-OLinuXino-1

We complete our test with Rev.B

Good news is that Gigabit interface works well with Micrel/Microchip PHY and result is real Gigabit bandwidth. A20 although having Gigabit interface can’t make more than 700 Mbit I guess this is related to A20 capability to handle the data from GMAC. With A64 the speed is  932Mbit i.e. very close to 1Gb:

root@A64-OLinuXino:~# iperf -s 
 ------------------------------------------------------------ 
 Server listening on TCP port 5001 
 TCP window size: 85.3 KByte (default) 
 ------------------------------------------------------------ 
 [  4] local 10.0.0.4 port 5001 connected with 10.0.0.1 port 41144 
 [ ID] Interval       Transfer     Bandwidth 
 [  4]  0.0-10.0 sec  1.09 GBytes   932 Mbits/sec

 

For eMMC we followed the advice to make it dual voltage 3.3V and 1.8V with aim to have faster transfers and we implemented it in the hardware, but the tests show that transfer is same even at 1.8V is a bit lower. I don’t know if this is due to lame software settings we do in the eMMC drivers, or just the eMMC we use have same transfer on both voltages (we check datasheet and the eMMC we use have same speed quoted on both voltages), so this may be useless for our eMMC chip:

eMMC clock: 52 Mhz

eMMC@3.3V 
root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/mnt/output conv=fdatasync bs=384k count=1k; rm -f /mnt/output 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB, 384 MiB) copied, 33.0437 s, 12.2 MB/s 
 
eMMC@1.8V 
root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/mnt/output conv=fdatasync bs=384k count=1k; rm -f /mnt/output 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB, 384 MiB) copied, 37.9408 s, 10.6 MB/s 
 
SDMMC clock: 40MHz 
 
SDMMC@3.3V 
root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output 
1024+0 records in 
1024+0 records out 
402653184 bytes (403 MB, 384 MiB) copied, 41.1578 s, 9.8 MB/s 
 

With SDMMC as we don’t know what SD card will be inserted the clock is set to default 40Mhz.

After re-checking that everything works, we make last cosmetic changes to audio part we noticed in the last moment and will run Rev.C in production.

A64-OLinuXino-eMMC rev.B OSHW 64 bit ARM development board prototypes are testing

A64-OLinuXino-1

A64-OLinuXino-2

What you see is our improved REV.B of A64-OLinuXino. What’s new:

  • Gigabit PHY is now KSZ9031 from MICROCHIP/MICREL which allow board to be produced in both commercial and industrial grade!
  • DDR3 is now DDR3L for lower power
  • we add SPI flash footprint U12
  • Audio input now is jumper selectable between LINE-IN and MIC-IN
  • eMMC now can work on software selectable voltage 3.3V or 1.8V which would allow faster speeds
  • status LED is attached to port PE17
  • size 90×60 mm

Now we do final software tests and if everything is OK we will run production.

 

Previous Older Entries