RE: RACHEL running on the BRCK!

[Mark Knittel]

Ed: I sat down with the students today to look at what they had setup. In this case they were using KA Lite from the 64gb load, running over a LAN configuration to the Raspberry Pi. We had 20 devices loaded at once, all running KA videos, and they were all loading very quickly, and running without a hiccup. In addition, when I started a 21^st machine to see if I could browse easily through the rest of Rachel easily, open books, etc. it did that without any hesitation. The browsing response time was very quick. We might have been able to get more machines running to test the limits of the processor, but we ran out of time before we had to free up the lab again. We were not able to switch between versions of KA. However, this part of the test was very encouraging. If we had run into a problem we might have been able to turn on some network trace equipment to look for the source, but there was no need to do that in this case.

 

In about 10 days I’m going to go back so that we can try to do the same thing with direct wireless connections from Rachel (on laptops) to the Raspberry Pi. I’d like to do it that way so we can compare the performance to the LAN test to see if there is any difference. My concern is that the wireless adapter might place a greater load on the processor, depending on whether more of the wireless protocol and/or IP stack has to be processed in the main processor than with the LAN configuration. I don’t have any facts to back that up, but I’ve seen that occur in the past with other systems, so I wanted to make sure there was not a problem with this configuration. If anyone knows what the differences in processor load might be from each adapter type I would appreciate it.

 

Mark Knittel

Owner, Ovation Technical Services

Board Chair, Technology Alliance Group Northwest (http://tagnw.org)

Bellingham, Wa. 98229

360-441-2126

 

From: Ed Resor [mailto:edr...@gmail.com]
Sent: Thursday, May 22, 2014 6:36 AM
To: Mark Knittel
Cc: Pat B4H; Bro. Emmanuel SMB; Loum Crinima; Owiny K. David; Owilli Nelson; Sa'dan Sulehri
Subject: Re: RACHEL running on the BRCK!

 

Mark,

 

Thanks for setting up objective and replicable test of the RACHEL Pi.  Would it be possible for you to try some or all of the configurations below.

 

I think for your plans for primary schools associated with the Conservancy you will want to test 1.) and not just 2.).

 

For comparison with the lab tests by Orange in the research labs in France, 1.), or more likely 3.), would be closest.

 

1. RACHEL Pi with WiFi dongle and regular Khan Academy

2. RACHEL Pi with WiFi dongle and KA-Lite interactive Khan Academy

3. RACHEL Pi with wired connection to WiFi router or access point and regular Khan Academy

4.   RACHEL Pi  with wired connection to WiFi router or access point and KA-Lite interactive Khan Academy

 

Let me know if you need help finding the two different SD Card images for regular Khan Academy and KA Lite.

 

I estimate that:

 

1. Will be best configuration for starting in rural primary schools because of simpler software and hardware and fast enough.  You might want to try different WiFi dongles for more range and may need to add the Linux drivers for the dongle you choose.

 

2. KA-Lite as currently implemented seems to slow things down significantly and be beneficial only for an extremely innovative school and probably not useful in the first year except for special secondary schools.

 

3. Offloading the WiFi connection and access control will be easiest way to increase the capacity to serve more users and to increase range at the same time.  A router that can be powered with DC from a 12 volt solar system and replaced from Nanyuki or Nairobi would be great especially if it had as USB port to power and connect to a GSM data modem for an uplink to the Internet.

4. This configuration will speed up KA-Lite and increase range.

 

Your tests will also provide a way to compare the RACHEL Pi with the RACHEL BRCK.  You will note in the specs that the BRCK has a slower processor and probably less than the 512 MBytes in the Raspberry Pi's CPU.

 

Please post your test procedures and results as special discussion topic the RACHEL Project Google Groups.  If you cannot all four of the configurations suggested above I will try to encourage someone else to run the rest, possibly at students at WPI where my son is a student.

 

Thanks and good luck, Ed

 

On Thursday, May 22, 2014, Mark Knittel <Ma...@ovationtech.net> wrote:

Hi Ed. I have not really done any detailed look at tablet options yet. I am very impressed with Samsung, but their price point puts them out of range of this application. I am more inclined to try a tablet to risk a lower cost device since there is little/no maintenance to do on them, and it would be easier to replace one if needed.

 

BTW: I’m going to see the initial results of the Raspberry Pi/Rachel performance test tomorrow – I’ll let you know what I see.

 

Mark Knittel

Owner, Ovation Technical Services

Board Chair, Technology Alliance Group Northwest (http://tagnw.org)

Bellingham, Wa. 98229

360-441-2126

 

From: Ed Resor [mailto:edr...@gmail.com]
Sent: Wednesday, May 21, 2014 2:04 PM
To: Pat B4H
Cc: Bro. Emmanuel SMB; Loum Crinima; Owiny K. David; Owilli Nelson; Sa'dan Sulehri; Mark Knittel
Subject: Re: RACHEL running on the BRCK!

 

Team,

 

I am ready to provide some back up for the Ubislate.  When Pat lets me know they have been shipped, that will give me another prod to try side loading some alternative browsers and other potentially helpful applications into the UbiSlate I have here in New York.

 

If anyone with a working UbiSlate can back up and email me the browser they prefer, I will sideload that browser and write up a guide if I am successful.  It won't be a perfect guide because my UbiSlate is no longer fresh out of the box, but it should help.

 

Mark,

I am interested it what tablets you are considering for you work for kids in primary schools on or near the Ol Pejeta Conservancy, west of Nanyuki town and airport.  Although not that far from Nanyuki, the lack of power and the limited development could be similar to some of the more rural locations where we would like to have Skills Empowerment Centers in Karamoja, particularly in terms on 100% solar power and rough, dusty conditions.

 

Best to all, Ed

 

On Wed, May 21, 2014 at 3:59 PM, Pat B4H <p...@bicycles-for-humanity.org> wrote:

Hi Ed

 

 

 thanks, hopefully next week, i will ship a number of tablets to uganda to test.  Once we know what works, we can go from there.  I think the raspberry with rachel and the ubislate  is worth testing in the field

 

 

 pat

On May 21, 2014, at 11:44 AM, Ed Resor <edr...@gmail.com> wrote:

 

Teams,

 

This is very early news.  The news is not up yet on either the BRCK or the RACHEL Development web sites.  We cannot count on using this platform soon, but I think the BRCK platform for RACHEL plus smartphones sold to customers for as little as $25 should be included in our plans as technology that could be available by the end of 2014.

 

Just so you can appreciate that this is real, I have attached 3 photos from Johnny Long.  Note the use of the very short USB Leef Flash Drive to minimize the risk of being broken by someone handling the BRCK.

 

For those who like to review spec sheets, I have attached a spec sheet with some of my comments highlighting features that will help with the work we are doing.

 

The good news is that this final (I hope.) delay is for a problem with the case.  Units were supposed to ship May 15.  Since the case is the problem, a number of units have gone out for testing of everything else.  The latest update on the production problems and a video of the factory in Texas are here:

http://www.brck.com/blog/  

 

That last mention that I saw of the price for the BRCK was $199 once all of the Kickstarter supporters and pre-orders were filled.  In light of problems getting the BRCK out, this price could be higher.  If you register at this link, you will know as soon as the BRCK is available to buy online.  http://www.brck.com/get-a-brck/  .

I am waiting for one BRCK from my Kickstarter participation and two more from pre-

--

Edmund Resor
Development Adviser, Catholic Diocese of Torit, South Sudan
www.CatholicDioceseofTorit.org   www.KuronVillage.net
New York City Home/Office +1 212 873-5464
Cell phones in Sudan MTN 092 615-6327 Vivacell 0956 716 504

 

[Ed Resor]

Mark,

Great news!

We can now rest assured that we have a lot of capacity to server KA-Lite from the Raspberry Pi for when and where we.  Moreover, this capacity increase can be realized with inexpensive, easily maintained equipment available in practically any country, i.e. simple "wireless" routers* which can be used to off loading the routing and WiFi management tasks.  In addition, the extra power consumption from modern wireless routers is very low thanks the efficiency standards set by the European Community.

I agree that the extra duties on managing WiFi could slow things down, possibly a lot.  I did not notice a problem with the WiFi until I tried KA-Lite.  I have shipped those units as they were fast enough.  I will try to rebuild one this weekend; however, I can only muster about 4 devices unless the kids are home or we have guests.

For the BRCK, one easy capacity increase would be a RACHEL Pi connected with a wired Ethernet cable.  I expect, and hope, other integrations between the BRCK and the Raspberry Pi board could be even better, possibly including power for the Raspberry Pi from the BRCK and its battery, using a communication link that leaves the one Ethernet Jack on the BRCK open for other use, and triggering orderly shutdown of the server running on the Raspberry Pi as the remaining battery power runs low.

Best, Ed

* "wireless" router refers to routers that include wireless access points and most often 4 wired 100 Mb/s Ethernet LAN jacks and one Ethernet WAN jack for upstream connections.  The old bulky blue Linksys WRT54G series including early and very popular examples, with many good, lower cost competing models available for about $25.

[Johnny Long]

Sam will jump in here. The power must be bumped to 5.4v. There is a significant enough draw from the wifi card to reboot the Pi. This is why Sam uses the pololu. Sam?

Johnny

On May 23, 2014, at 10:21 AM, Mark Knittel <Ma...@ovationtech.net> wrote:

Ed: I sat down with the students today to look at what they had setup. In this case they were using KA Lite from the 64gb load, running over a LAN configuration to the Raspberry Pi. We had 20 devices loaded at once, all running KA videos, and they were all loading very quickly, and running without a hiccup. In addition, when I started a 21^st machine to see if I could browse easily through the rest of Rachel easily, open books, etc. it did that without any hesitation. The browsing response time was very quick. We might have been able to get more machines running to test the limits of the processor, but we ran out of time before we had to free up the lab again. We were not able to switch between versions of KA. However, this part of the test was very encouraging. If we had run into a problem we might have been able to turn on some network trace equipment to look for the source, but there was no need to do that in this case.

 

In about 10 days I’m going to go back so that we can try to do the same thing with direct wireless connections from Rachel (on laptops) to the Raspberry Pi. I’d like to do it that way so we can compare the performance to the LAN test to see if there is any difference. My concern is that the wireless adapter might place a greater load on the processor, depending on whether more of the wireless protocol and/or IP stack has to be processed in the main processor than with the LAN configuration. I don’t have any facts to back that up, but I’ve seen that occur in the past with other systems, so I wanted to make sure there was not a problem with this configuration. If anyone knows what the differences in processor load might be from each adapter type I would appreciate it.

 

Mark Knittel

<image001.png>

<image001.png>

--
You received this message because you are subscribed to the Google Groups "RACHEL Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rachelprojec...@googlegroups.com.
To post to this group, send email to rachel...@googlegroups.com.
Visit this group at http://groups.google.com/group/rachelproject.
To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/6f8085ce55a2480688f04833ab9f6c36%40BY2PR05MB096.namprd05.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[Johnny Long]

However BRCK+Pi is redundant especially now that the BRCK is running Rachel. 

Still nervous about Pi here in Uganda. 

There are no parts an no one to support it. At least the BRCK can be flashed remotely (via cloud/3G) if it's software crashes. 

Johnny

--

You received this message because you are subscribed to the Google Groups "RACHEL Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rachelprojec...@googlegroups.com.
To post to this group, send email to rachel...@googlegroups.com.
Visit this group at http://groups.google.com/group/rachelproject.

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/64321bcf-54cc-451d-b6ca-efb58c27bb1a%40googlegroups.com.

[Sam Kinch]

The remote flash is a sweet option. 

Couple of things re power and Pi:

- we boosted the voltage to 5.4V out of the Pololu to account for line loss 

- we use the Pololu primary to clean and boost voltage when on internal battery as we are using 3.7V 26Ah batteries and the Pi definitely needs 5V

- we use a 2A power plug (very important) as the wireless dongle will suck a good .7-.9A when there are a lot of clients sucking data

My dream device is one piece from power input to product. Remotely accessible via ssh and remotely flashable. Locked down for content delivery and admin mgmt. Sync when online for content updates.  Inexpensive to replace. Backup config options. Ruggadized. Built in access point and Ethernet. SD card slot. Additional usb power port for charging phone. 

Sam

[Johnny Long]

On May 25, 2014, at 5:37 AM, Sam Kinch <s...@hackersforcharity.org> wrote:

The remote flash is a sweet option. 

Couple of things re power and Pi:

- we boosted the voltage to 5.4V out of the Pololu to account for line loss 

- we use the Pololu primary to clean and boost voltage when on internal battery as we are using 3.7V 26Ah batteries and the Pi definitely needs 5V

- we use a 2A power plug (very important) as the wireless dongle will suck a good .7-.9A when there are a lot of clients sucking data

Thanks for clarifying Sam. Appreciate you. :-)

My dream device is one piece from power input to product. Remotely accessible via ssh and remotely flashable. Locked down for content delivery and admin mgmt. Sync when online for content updates.  Inexpensive to replace. Backup config options. Ruggadized. Built in access point and Ethernet. SD card slot. Additional usb power port for charging phone. 

Sam would you be available next week to work with the BRCK team if needed? We are looking at having all of these features out of the gate. I think you could really do wonders working with this team. I'm likely going to be in Nairobi next week working with them. Thoughts?

[Mark Knittel]

Johnny/Sam: What is your expectation of the cost of the BRCK and how many simultaneous users it can support?

 

Mark Knittel

Owner, Ovation Technical Services

Board Chair, Technology Alliance Group Northwest (http://tagnw.org)

Bellingham, Wa. 98229

360-441-2126

 

[Johnny Long]

Right now it's $200 and it will support at least 20 users. I'm field testing it now. Maybe more users. 

Johnny

On May 28, 2014, at 7:03 AM, Mark Knittel <Ma...@ovationtech.net> wrote:

Johnny/Sam: What is your expectation of the cost of the BRCK and how many simultaneous users it can support?

 

Mark Knittel

<image001.png>

[Mark Knittel]

That’s pretty impressive – it sounds comparable to the Raspberry Pi. Do you think both are needed, or are they redundant? If not, is anyone looking at trying to harden and make a manufacturable version of the BRCK?

 

Mark Knittel

Owner, Ovation Technical Services

Board Chair, Technology Alliance Group Northwest (http://tagnw.org)

Bellingham, Wa. 98229

360-441-2126

 

[Johnny Long]

The BRCK is FCC and CE certified and will be available for retail purchase all over the world but starting in Kenya and us. Kick starter backers get their units in June. And the BRCK is pretty hardened. I'm already impressed with the durability. We are working on the cloud interface now. 

Johnny

On May 28, 2014, at 7:22 AM, Mark Knittel <Ma...@ovationtech.net> wrote:

That’s pretty impressive – it sounds comparable to the Raspberry Pi. Do you think both are needed, or are they redundant? If not, is anyone looking at trying to harden and make a manufacturable version of the BRCK?

 

Mark Knittel

<image001.jpg>

[Johnny Long]

The BRCK may very well make the Pi redundant but we are looking at ways to 

Make them work together. 

Johnny

On May 28, 2014, at 7:22 AM, Mark Knittel <Ma...@ovationtech.net> wrote:

That’s pretty impressive – it sounds comparable to the Raspberry Pi. Do you think both are needed, or are they redundant? If not, is anyone looking at trying to harden and make a manufacturable version of the BRCK?

 

Mark Knittel

<image001.jpg>

[Jeremy Schwartz]

Though I love the BRCK, I'm not convinced it replaces a true processor.  I need to do more diligence here, but I haven't seen it actually run MySQL or handle the databases we need to run a search.  It might also be lacking in its ability to serve Python content (needed for KA-Lite). 

From reading the specs, I see BRCK as much more a complement to a lightweight server (of which the Pi is one).  I have been playing with Keedox's QuadCore Android MiniPC.  With 2GB of RAM, power support for an external SSD, and a user friendly Android OS, I would say this far surpasses the Pi in terms of a good field server.  It costs less all put together also, in a much more durable way.

The trickier part right now is putting it together.  The Pi is great because the image includes a configured OS.  I'm not versed enough in android to figure out how to create a downloadable image for it.  Instructions are here if you want to see them (including videos).

To be clear, any Android device can be the server.  I'm running RACHEL (w/ search) off a $45 tablet.  Battery and screen make it even easier.

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/A1E85E0F-B099-4C24-81A3-8867634996D3%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

(m) 415.535.2138

[Johnny Long]

Some Specs on my BRCK:

BusyBox v1.19.4 (2014-03-19 12:08:06 EAT) built-in shell (ash)

Enter 'help' for a list of built-in commands.

  _______                     ________        __

 |       |.-----.-----.-----.|  |  |  |.----.|  |_

 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|

 |_______||   __|_____|__|__||________||__|  |____|

          |__| W I R E L E S S   F R E E D O M

 -----------------------------------------------------

 ATTITUDE ADJUSTMENT (Attitude Adjustment, r39585)

 -----------------------------------------------------

  * 1/4 oz Vodka      Pour all ingredients into mixing

  * 1/4 oz Gin        tin with ice, strain into glass.

  * 1/4 oz Amaretto

  * 1/4 oz Triple sec

  * 1/4 oz Peach schnapps

  * 1/4 oz Sour mix

  * 1 splash Cranberry juice

 -----------------------------------------------------

root@OpenWrt:~# cat /proc/cpuinfo 

system type : Atheros AR9330 rev 1

machine : TP-LINK TL-MR3020

processor : 0

cpu model : MIPS 24Kc V7.4

BogoMIPS : 265.42

wait instruction : yes

microsecond timers : yes

tlb_entries : 16

extra interrupt vector : yes

hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0300, 0x0c60, 0x0860]

ASEs implemented : mips16

shadow register sets : 1

kscratch registers : 0

core : 0

VCED exceptions : not available

VCEI exceptions : not available

root@OpenWrt:~# cat /proc/m

meminfo  misc     modules  mounts   mtd

root@OpenWrt:~# cat /proc/meminfo 

MemTotal:          29324 kB

MemFree:            5136 kB

Buffers:            2428 kB

Cached:             7936 kB

SwapCached:            0 kB

Active:             7968 kB

Inactive:           5316 kB

Active(anon):       3008 kB

Inactive(anon):       64 kB

Active(file):       4960 kB

Inactive(file):     5252 kB

Unevictable:           0 kB

Mlocked:               0 kB

SwapTotal:             0 kB

SwapFree:              0 kB

Dirty:                 0 kB

Writeback:             0 kB

AnonPages:          2936 kB

Mapped:             1680 kB

Shmem:               152 kB

Slab:               6392 kB

SReclaimable:       1236 kB

SUnreclaim:         5156 kB

KernelStack:         496 kB

PageTables:          536 kB

NFS_Unstable:          0 kB

Bounce:                0 kB

WritebackTmp:          0 kB

CommitLimit:       14660 kB

Committed_AS:       9304 kB

VmallocTotal:    1048372 kB

VmallocUsed:         856 kB

VmallocChunk:    1040660 kB

Johnny

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/CANNQo7yWKyzUffPWbLVMhbZSPK0z0wRgLZXf5Y9UE-2sEhUukQ%40mail.gmail.com.

[Jeremy Schwartz]

Well we can install a lamp stack on openwrt, would have to see if it has the processing power and ram to do something with it though.

Processor: 0

Doesn't give me lots of confidence at this point. Would have to rely on someone who knows more than me 

+1.415.535.2138
Sent from my mobile

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/35217825-5CD1-423F-BF71-88F22EB9AE90%40gmail.com.

[Johnny Long]

Jeremy-

Thanks for the info. Super excited about the android server. Good stuff!

One thing that I see from this side of the pond is that it's impossible to keep up with all these "tinkerer" solutions. It seems there is a new gee-whiz better-than-the-Pi solution every day. 

We simply don't have parts for these solutions. I can't get reliable shipments from adafruit or any other parts distributor and even if I could, I'd be taxes at more than the value. Further I'm having a really hard time finding techs that can do repairs that I can trust. My most trusted tech is in jail for a second theft of thousands of dollars. 

East Africa (which I can speak to as opposed to other places) doesn't need a solution that's constantly moving. We need something that's durable, resilient, remotely manageable, locally replaceable if not locally repairable. That's the BRCK. 

I'm a geek. You know that. I love to tinker. I love the solutions that are coming up faster than we can but them. But I'm tired of being the only one that can support or understand them. In cities you may find techs and parts soon but the rural areas we target and serve simply can't support anything even as complicated as the Pi. 

That's why right now I'm working so hard on the BRCK. Because once we have it loaded I know I won't have to worry much once it's fielded. 

Thoughts and comments always welcome. 

Johnny

On May 28, 2014, at 8:10 AM, Jeremy Schwartz <schwart...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/CANNQo7yWKyzUffPWbLVMhbZSPK0z0wRgLZXf5Y9UE-2sEhUukQ%40mail.gmail.com.

[Jeremy Schwartz]

Hey Johnny,

I see your point for sure.

While the videos use an android pc, it is the same install as any Android device which sits already in the hands of billions. I only use the android pc because it's easier to record the video.  The joy of this is that there are precisely no new parts or new support for all the reasons you mention. Anyone with an Android phone, 15 minutes and Rachel content can open a server. I don't really see it as a tinkering solution but one that addresses the hardware problem we see in east Africa and elsewhere by eliminating it.

My only comment on BRCK is that I think we might loose a lot of functionality that some people like. I'm actually not sure if that's true or not. Just trying to investigate.

+1.415.535.2138
Sent from my mobile

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/31C89EC3-2140-4926-AAC7-ED945AD3D8D9%40gmail.com.

[Johnny Long]

On May 28, 2014, at 9:26 AM, Jeremy Schwartz <schwart...@gmail.com> wrote:

Hey Johnny,

I see your point for sure.

While the videos use an android pc, it is the same install as any Android device which sits already in the hands of billions. I only use the android pc because it's easier to record the video.  The joy of this is that there are precisely no new parts or new support for all the reasons you mention. Anyone with an Android phone, 15 minutes and Rachel content can open a server. I don't really see it as a tinkering solution but one that addresses the hardware problem we see in east Africa and elsewhere by eliminating it.

I absolutely love that. Zack for example uses an android phone as a client. So that could be a server along with the tplink we have him. Together with the chromebook client he will be rocking. 

Did you notice in the post that I installed Rachel USB on the chromebook? That way he can use the static content no problem but also copy it from the glued and write locked sd card safely to other machines. Cool. 

My only comment on BRCK is that I think we might loose a lot of functionality that some people like. I'm actually not sure if that's true or not. Just trying to investigate.

Bear in mind that local content on the BRCK is a stopgap. We hope to bypass ka lite in favor of a mod rewrite solution that will Allow students to surf through it to khan online (taking advantage of the khan account tracking and exercises) then play the local video if available. This means a whole class could be online with khan using minimal bandwidth. The next phase would include the ability to switch off downloading videos and a feature to capture new videos as needed. 

As you said this might require another device powered by the brcks USB and attached to Ethernet. But we will see. One step at a time. 

Johnny 

To view this discussion on the web visit https://groups.google.com/d/msgid/rachelproject/CANNQo7w31p-vf4a%2BzK2w_Zz%3DQ%3DnRtik5z7y-1Z%3DkUcj4Zj5xTg%40mail.gmail.com.

[Ed Resor]

Guys,

I am posting this just on the list to lessen the email and tech load on the team in Karamoja. I will forward them a copy of this email and explain how to sign into the RACHEL Projects Google Groups so they can check in when they feel like it.

I agree with Johnny and his field bias.  (I am a few emails behind.)

• Even if the BRCK only runs the static version of Khan Academy, it provides a good, solid launch platform for RACHEL.
  It may have enough power for some patient KA-Lite users; however, hosting KA-LIte a separate hardware module could be very helpful.
  

We might offer users the option of installing KA-Lite directly from Learning Equality.  It seems inefficient to have to pieces, but look at Google and Amazon.  KA-Lite also includes its own system for collecting very good usage and status statistics and may have rewards in terms of badges, etc. that it can provide in return for these reports.

For growth, I also think we should have a simple and modular way to add another server on to the local LAN.  This server could be a range of things such as one of my favorites an old Windows laptop, with a static IP address set in its wireless adapter, or a wirelessly connected Android platform also set up with a Static IP address, or a Raspberry Pi, or a Linux box, etc.

Users would just need to learn how to type the different IP addresses for different servers into their browsers, or to set up two different icons on their client device.  Maybe we could figure out how to set up the links in the RACHEL Server on the BRCK to the second web server on a second IP address.  We could all pick some static IP addresses such as BRCK default x.x.x.5 and stick with them.  Alternatively, someone smarter than me could program another web page for the RACHEL Server on the BRCK with a little dialog for the end users to enter the address of the second server into the RACHEL Server of the BRCK for it to use for all calls on that second server. I home we will not need to install a full Name Server.

{Ain't  TCP/IP and HTTP great protocols for simple folk like us who have nothing to hide and like to give stuff away.  They evolved in universities and then came out and killed the X.25 protocols developed by telephone companies that were profit maximizing or worse, money hungry government monopolies dependent upon cross subsidies. I was there, I saw it happen. Buy me a few beers sometime.}

• The BRCK's ability to send back status updates and usage statistics will really help all of us on both sides of the pond, including remote user.
  

Johnny mentioned this earlier, but he was too politically correct to say that users are sometimes embarrassed and hesitant to report that their systems are down. They believe it is their fault and they should read their manuals, troubleshoot it, and fix it themselves.  They just have a lot of other squeakier wheels.  A friendly message (squeak) saying we miss you can often get the real status and a report on the problem that they have been holding back.  Also, it is quite often not their fault, and we learn something.

The BRCK can be carried from areas with no Internet coverage on a bike, a bus, a truck, or a plane to be synced up or reflashed and checked out at a location with Internet coverage.  Sometimes, the BRCK would just need to be walked from the school, where the teachers and students have no Internet access, to the administration office which does have Internet for reporting and fund raising.  This is my biggest problem in all of the locations I am trying to support.

I like the Android platform for a server because of the built-in battery and the rapidly declining costs of the hardware that result from mass production.  (Jeremy, which $45 tablet are you using?)

I like using a wireless connection from the Android or other server to the LAN because the BRCK (and the lower cost TP-Link MR3040) has only one Ethernet Jack and may need to use it as a WAN jack for a connection to a VSAT uplink or some other hardware.  Also searching for a WiFi network is an intuitive process that is becoming a global skill.  So the server should be easy to set up, especially if it has some kind of self-dimming, visual interface, such as an Android tablet or phone, or a Windows laptop.  (The lack of a low cost visual interface is a bit of a problem with the RACHEL Pi, even though there is a good reason for the lack of a low-cost screen.)

Wireless has the another advantage over wired, the low cost equipment coming out now and in the future is likely to be WiFi only for its Ethernet LAN connection.  Android tablets are a great example of this.  A good feature of the BRCK and the TP-Link MR3040 (now $45 new at reliable U.S. suppliers) is full routing capabilities for the LAN so multiple web servers and other servers are automatically supported.  Two more reasons for wireless LANs,, many locations have limited wired LAN jacks and do not want to buy switches and wires can have ground loops which can fry equipment.

{I am concerned that many of the low cost "hot spots" sold and partially subsidized by cell phone operators as well as many smartphones acting as "hot spots" do not do the routing needed to support a server on the wireless LAN.  I will continue to investigate this problem as a subsidized hot spot could provide a wireless LAN that would be a lower cost solution than the BRCK or MR3040, be locally supported by the cell phone network operator, and be reasonably user friendly.  There are more and more wireless hotspots in the field because they provide the new revenue from data services that network operators need to pay for their network upgrades in a time of dropping per minute charges for voice and Apps like Mxit and WhatsApp eliminating revenue from SMS messages.  Mesaging apps with voice over over IP (VoIP) are now threatening revenue from international voice messages.  (As I said these are great protocols, and I forgot UDP.)  For a location using a cellular hotspot as a router, the wireless server, on the Android platform for example, should be able to report status and collect and report usage statistics.}

  

The BRCK is managed by a smartphone app which should get easier and easier to use.  This is important, and not just for sales  to iPhone users in the U.S. and Europe who don't understand network address translation and the difference between static and dynamic IP addresses.

All for now, Ed

On Friday, May 23, 2014 3:21:44 AM UTC-4, Mark Knittel wrote: