Jump to content

Recommended Posts

Posted
29 minutes ago, Tido said:

Why did you choose  the one with a hinge   and not:

Hirose DM3CS (Hinge, Push-Pull, manual, without ejection mechanism)

Hirose DM3AT and DM3BT (Push - Push, with ejection mechanism)

Hirose DM3D (Push -Pull, manual, without ejection mechanism)

Can not recall now. I remember thinking about footprint. But also it may be this one was available at TME those days. From the other hand the cards are inserted once so way of installation is not so important. At least to me. 

Posted
1 hour ago, Igor said:

FYI. I am talking with Olimex

better to know late than never ;)

 

1 hour ago, Hijax said:

the cards are inserted once

under this circumstance it doesn't matter, unless you have to open it now and then for some unforeseen reason. That said, I would go for "Push - Push, with ejection mechanism" to be on the save side. The SDcard-Mux is inbetween and the Serial-Multiplexer on top - if I understand that correct. So, a replacement of the SDcard would force you to take it apart.

 

Posted

The distance between hats are about 22mm. Enough to open latch and remove / insert SD card. 
 

Having said that,  now I am not able but hopefully shortly Igor could check that. 

Posted
On 4/12/2020 at 6:59 PM, Igor said:

I am talking with Olimex to produce this board

 

Did you see this information (on page 4), the Google Doc represents the latest findings:

Quote

I think the 2 last parts, 74LS151 and 74LS157, should be HC not LS, since HC is 3.3V compatible but not LS which are 5V only ...

 

Posted

PCB's are in the mail - now component ordering: can someone double check and update original BOM with latest changes. We want operational boards, right? :) 

Posted
3 hours ago, Igor said:

and update original BOM with latest changes

just visit the google docs in this thread on page 4 I guess

Posted
On 4/14/2020 at 10:31 AM, Igor said:

Tests are still distant from perfection

is it a good time to get a fresh copy from Github and run it again ?

 

Do you need some help?

Posted
7 hours ago, Tido said:

Do you need some help?

 

Just git pull to update the scripts locally.


... if you have time, manual is outdated. 

Posted
47 minutes ago, Igor said:

if you have time

well, depends on the person, but as I use to say: It is not whether you have time, it is whether you take the time ;)

 

SBCBENCHPASS=${PASSES}	# sbc-bench will run on each cycle by default, set to 1 to run only on first

{PASSES } will be read from the first line of the configuration file, but I don't know this SW SBCbenchPass, what is it?

 

UPLOAD_SERVER=""			# server for report upload
UPLOAD_LOCATION=""			# location on that server

To do that and to filter my results, wouldn't each person need a unique, but requrring identity?

 

Looks like it has some troubles with:

iperf-on-all-interfaces.include: Line 20: iperf3:

It started:

[ o.k. ] 0. Trying [ 19:01:15 - 11.5 ]
[ o.k. ] 0. RockPi-4B Linux 4.4.213-rockchip64 stable [ 19:02:02 - 11.5 Uptime:  2:17 ]

still not finished with 2 Passes at 20:31

 

 

Although I repeat myself of 31. March:

there is no information given, that my system is downloading software. I hate these kind of installer like Firefox, TEAMS and    armbian autotests.

Do you mind to add a line like: It needs the following software;....,  if not already installed it will install it now:  (list the software)

 

Posted
54 minutes ago, Tido said:

To do that and to filter my results, wouldn't each person need a unique, but requrring identity?

 

I don't count more then a few people doint this. But not at this stage - utility is very bugy as you can see. We don't do nothing with the data yet - only collect and upload.

 

54 minutes ago, Tido said:

{PASSES } will be read from the first line of the configuration file, but I don't know this SW SBCbenchPass, what is it?


I took @tkaiser sbc-bench as a core tool for making a load + generate numbers. There its defined how many times this test is run. You can run test per board many times but you don't run sbc-test each time. In my real tests I do 3 passes of tests but I only run sbc-test in first run. But sometimes I want to compare number and ... Don't bother with this. Tests scenarios is not something you need to document nor understand.

 

54 minutes ago, Tido said:

there is no information given, that my system is downloading software.

 

I will start to care about that perhaps next year, if I will be the only user, never. My main concern is that app becomes usable, that additional hardware can be implemented, ... not what users might think about. Look on this as an internal tool.

Posted

@Igor, after fiddling around with: systemd-analyze time  -  this would be a valuable information on the testing, wouldn't it?

:~$ systemd-analyze time
Startup finished in 54.100s (kernel) + 1min 30.978s (userspace) = 2min 25.078s 
graphical.target reached after 1min 30.924s in userspace

fun fact, is the server build but it says: graphical.target reached after 1min 30.924s in userspace

 

Posted
1 hour ago, Tido said:

this would be a valuable information on the testing, wouldn't it?


Absolutely.

 

You can try to add a test for that, after 7z.

Posted
4 hours ago, Igor said:

after 7z

0119-7-zip-benchmark.bash -  I would have put that before starting any test, so I had a first value in case anything goes south.

Another idea is to collect the values (strip out the numbers).. I left mine in english what if it is in another language, can regex extract that..  just looked at the man-page even better if there is a command that only returns the values - cannot see one right away.

Collect the values of several passes in a global array and report only the best and the worst.

 

Posted


One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.

After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...

Posted
1 hour ago, Hijax said:

I hear ZX spectrum :)

 

You hear right :D 

Posted
23 hours ago, Igor said:

 


One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.

After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...

 

 

 

that's super awesome @Igor!

Posted (edited)

Edit: replaced with hires pictures.
 

P1170855.JPG

P1170864.JPG

P1170868.JPG

P1170874.JPG

Edited by Igor
Better images
Posted

Nice. But one 2x5 connector shall have long legs. To allow interconnection between boards/ stacking of them on top of SBC

Posted
1 hour ago, Hijax said:

stacking of them on top of SBC

to stack the green PCB on top of the blue PCB according to the pictures from @Igor , right?

Well, if only a THT part is wrong, easy. This is not ideal, but much easier than a wrong SMT item.

Posted
1 hour ago, Hijax said:

Nice. But one 2x5 connector shall have long legs. To allow interconnection between boards/ stacking of them on top of SBC


Yes. I also notice this and I hope that is the only problem ;) Will report later when I do the proper unboxing. I'll ship it ASAP. 

 

5 minutes ago, Tido said:

right?

 

Right.

Posted

Order of stacking: to make 7seg LED visible, I.e.

SBC -> Blue -> Green

 

When stacked, SBC shall be powered from this sandwich top board connector. SBC thus shall be able to switch ports, what shall be reflected on 7seg. 

 

7seg represents the port, serial lines (RX/TX) shall be routed to.

 

In princible  via I2C we program 16bit word.  Low byte is a power dsictribution, any of those bits control mosfets to power the connetced SUT SBC.

High byte is split into two 4bit chunks. Low control serial port mux, high are used by blue board to connect SD card.

 

Idea is, to be able to power all but one SUT-SBC, write data to SD card, release SD by SBC, power on specific  SUT-SBC using the SD we just modifying, wait for RS232 communication to confirm booting went OK.  In the meantine one can switch serial mux to other port to write something as terminal command.

 

 

Posted

OK, now that I have these in-hand.  The SD multiplexer board, for the 2x5 pin header, should that be a pass-through connector?  Mine are soldered with a socket facing downward on both boards.  Easy fix for me, maybe not for some of the others.  ;-)  All connectors are Mini-SPOX other than the SD card mini-board. the 1x4 pin header on each is populated, on the SD board it faces "up", on the serial board "down" I would assume one should be a socket.

 

[edit] Well, I was not on the recent page when I wrote this, haha.

Posted
On 3/24/2020 at 7:27 PM, Igor said:

When people will realise, when we will know how to tell them that, that stability of their systems depends from the things like this, then perhaps someone will also follow and wire stuff together, perhaps find it interesting to deal with and do it instead of me ... :)

 

This is essentially a (cool) tool for us to quickly see how things looks from the users perspective. Now and for the future. With most boards at once. If anyone wants to have this look or help to creates that looks, one shell join. But I don't expect people staying in the line to help out. Even its is in their, ours interest.

How does one acquire these marvelous boards? 

Posted
29 minutes ago, Technicavolous said:

How does one acquire these marvelous boards? 


By asking and if there will be some left ... ;) V1.0 has some troubles and we are working on a redesign https://github.com/armbian/mpads When we will get a new batch (ETA= unknown) I will send you one.

Posted

Serial and power mux board is ready for ordering. However before I do so, I need to wait till SD card mux board redesign is complete at least overall idea is “approved”.

 

As previously written the major change is to switch from simple SDI interface towards SDIO one allowing full speed communication with card. This requires 8 pins thus not only mux board but also card adapter tuning. 

Recently idea under consideration is to move SD mux board away from stacking and make it more alike USB Mass Storage device. 

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines