Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardware budget #56

Open
benhylau opened this issue Sep 18, 2018 · 13 comments
Open

Hardware budget #56

benhylau opened this issue Sep 18, 2018 · 13 comments
Assignees
Labels
ipfs-grant Supported by IPFS Research grant

Comments

@benhylau
Copy link
Member

benhylau commented Sep 18, 2018

One of the main difficulty in having other groups facilitate this workshop is hardware requirements:

With the IPFS Research grant, we can have some hardware budget, and I propose to have two pools:

CAD 1700 to stock currently-working devices

Item Units Cost (CAD) Total (CAD) Use
Raspberry Pi 3B+ with power 6 70 420 Shared resource for local facilitators
Toplinkst TOP-S5 + accessories (pigtails, antennas, USB header) 60 11 660 Shared resource and give/sell to collaborators
Samsung Evo Plus 32 GB 24 11 264 Shared resource and pre-image SDs to give/sell to collaborators if needed
LoRa hardware 20 15 300 Shared resource and give/sell to collaborators who run Module 6

Edited (25 Sep 2018): Added link to buy USB headers for wireless adapters.

According to this article the Samsung Evo Plus 32 GB seems like a good choice for write performance since we are likely going to be swapping a lot on the disk. The option with the case for $0.01 is also useful for labelling purposes.

CAD 300 to explore new devices

There are other radios that are interesting and it'd be great to have a budget to purchase some to explore. Current vendors we have a relationship with are Toplinkst, Dragino, and newly Alfa. The TOP-S5 satisfies most of our requirements (i.e. dual-band, 802.11s, external antennas, Linux drivers, cost) but there are still attributes that can be improved (e.g. range, stability, speeds, packaging, global availability, etc.) and it would be nice to not be completely dependent on one model.

We should also use this budget to explore the class of SBCs that:

  • Cost < CAD 15 (that's where it makes sense to start stocking them, sending out samples, sell in bulk for an entire class)
  • CPU processing power comparable to a Raspberry Pi 3B
  • RAM above 1 GB, even better if 2 GB
  • On-board WiFi we can configure as AP
  • e.g. Orange Pi Zero, NanoPi NEO (but these boards are currently 512 MB RAM and may not have on-board WiFi)
@benhylau benhylau added the ipfs-grant Supported by IPFS Research grant label Sep 18, 2018
@Shrinks99
Copy link
Member

Udit's LoRa demo is rad and I'm a huge fan however it does drive the cost of running the full workshop up and if I'm not mistaken is largely dependant on his hardware running Steamlink in Toronto. I think if we are considering stocking hardware for these purposes we should determine if we should keep or scrap module 6 due to it's uniqueness compared to the hardware used in the rest of the modules and, by extension its increased cost on a per workshop level.

I would also do more research into reputable SD card sales if you haven't already, there is a widely known scam where the drive will appear if it is 32 GB (or whatever is advertised) but in reality the card is something like a 4 or 8 GB drive and will overwrite/cause problems once you attempt to load anything over the actual drive limit. Easy to get burned on Aliexpress and Amazon like that.

@darkdrgn2k
Copy link
Contributor

I would also do more research into reputable SD card sales

I think those are the Chinese knockoffs. Not sure if the "Samsung branded" ones are the issue. The more reputable brands also do a better job in wear leveling.

Lora
I would much rather see a Lora + RPI based demo instead of Arduino, that way it would fit better into the package as a whole. Perhaps i can investigate separately and maybe put together a new mod 6 that fits better into the overall build.

@darkdrgn2k
Copy link
Contributor

Lora + RPI maybe?

http://wiki.dragino.com/index.php?title=Lora/GPS_HAT

@uditvira
Copy link
Member

Adding some details re:LoRa and Steamlink.

Steamlink has three components:

1. Node

The purpose of the node is to be a low power remote device for sensing and actuating.

We're currently using an Adafruit Feather which is powered by an ARM M0 chip. You can program it with a standard ARM toolchain but it has great support with the Arduino IDE making it extremely beginner-friendly

2. Bridge

A bridge is actually a node that supports two network interfaces instead of just one. The purpose of a bridge is to bridge the two networks, ie. MQTT messages that are received over a TCP/IP to the LoRa network.

We have been using a custom circuit with an ESP8266 interfaced with a standard LoRa sx1276 module from Semtech over SPI, but Steamlink bridges also work on boards like this one from AliExpress

In theory, we could interface a LoRa radio directly with a Raspberry Pi over SPI which is what the Dragino HAT does in a more user friendly form factor.

3. Store

The purpose of the store is to manage the network by monitoring radio links, updating routing information, and hosting the web console.

The store is implemented on Python. It can run on any linux machine, including a Raspberry Pi with a simple pip install.

Please see this repo for more info regarding Steamlink.


I agree with @Shrinks99 that it does drive up the cost of the hardware. Maybe module 6 could be an optional/stand alone piece over the long term.

Also agree with @darkdrgn2k that the LoRa stuff isn't that integrated with the rest of the ecosystem. Porting the nodes to Raspberry Pi hasn't been in the scope of Steamlink so far where the focus is more on low power devices. That being said, I think it would be very useful for applications such as running an out-of-band long-range admin channel for Toronto mesh nodes. If anyone else wants to take the lead on this work, I'd be happy to support their effort.

@benhylau
Copy link
Member Author

@Shrinks99 I think it will be great to have a LoRa / non-WiFi frequency component in the workshop series, because it's important to experience communication outside the realm of 2.4G and 5G, and start those discussions about tradeoffs (range vs. speed for example), where earlier components have built up concepts of. I am trying to get a realistic estimate of how much it would actually cost, and think we can definitely have hardware packages modularly distributed.

@uditvira the integrated board from AliExpress is much cheaper than a Adafruit Feather, is there a reason why we cannot use that same device for both Node and Bridge? What does setting up look like for the three components?

@darkdrgn2k while it is nice to see how LoRa can fit with a Raspberry Pi, it looks like the Dragino hat assumes Raspbian and requires quite a bit to configure. I wouldn't want there to be a need to deviate from existing Mesh Orange flow. It's better for any integration to be done in a way over more portable interfaces (e.g. on a separate board communicating with the Raspberry Pi over IP). In the future, if we move onto other boards (e.g. Orange Pi Zero), we are not stuck with having to redo Module 6.

@darkdrgn2k
Copy link
Contributor

I think it will be great to have a LoRa / non-WiFi frequency component in the workshop series

👍 I agreed i think exploring other open frequencies and protocols is important

Dragino hat
only reason i posed it because its an "easy" drop in and not pose to many other questions. I would rather see a different integration as well.

on a separate board communicating with the Raspberry Pi over IP

Longer term i think this is a bad model as the end goal for the lora with our mesh nodes is out of band communication. If its IP it cant really be out of band. I would suggest something like a serial link (that could easy be done via a USB-TTL connection. But this is a discussion for another time.

In conclusion
If we have module 6 ready to go i say lets keep using it. Im just saying my Hopes/Dreams/Wants would be to keep the fruitPi involved through out the workshop

If charlie ever finishes his heat map (for example) it may be nice addition to planning networks.

@uditvira
Copy link
Member

@benhylau

is there a reason why we cannot use that same device for both Node and Bridge?

None at all, you can absolutely do this. The feathers are slightly better quality and seem to be less finicky with different power cables, so we used them during the workshops.

What does setting up look like for the three components?

I created this repo to help with the setup. Let's track issues that are related to steamlink workshop setup there as they come up.

@benhylau
Copy link
Member Author

Due to 1 month lead time for Toplinkst order and we will likely need the adapters soon to move forward on some collab opportunities, I am going to put in an order for 60 pcs next week k?

@dcwalk
Copy link
Contributor

dcwalk commented Sep 30, 2018

Where are you shipping them?
Chatting with @darkdrgn2k in a similar vein at the picnic... with hardware arriving would be good to set up an inventory of the equipment that is "tomesh-owned" vs. personal

@benhylau
Copy link
Member Author

Can I ship to you @darkdrgn2k? Yea these are marked as tomesh. I wonder if it's possible to keep some stock with Ryan too?

@benhylau
Copy link
Member Author

Submitted order to Toplinkst for:

 60 units of TOP-4M02 (also known as TOP-S5 with RT5572 dual-band chipset)
120 units of SMA connector pigtails
120 units of 2 dBi dual-band RP-SMA antennas

Waiting on invoice.


I am also interested in ordering two of each of these:

  • TOP-3505 with rtl8192cu driver, which supports 802.11n 2.4G, ibss + mp, could be useful with this small form factor

  • TOP-8812 and TOP-5M02 for experimenting with rtl8812au driver, which may support 802.11ac 2.4G + 5G, ibss

    Notes from Access Point Mode gnab/rtl8812au#6:

    My phone (Samsung S7) connects at 866 Mbit/s ... to 8812AU based AP. It works on all Armbian builds out of the box with a kernel 4.9 or higher.

    Those 8811/8812 & 8814AU chips usually come with USB3 (but can work on 2.0 if powering is done properly) can easily draw 600-700mA and Rpi is not able to secure even 500mA.

    My 8812au sucks up to 600mA (measured with a normal multimeter, which is not very fast which means spikes can be higher) ... enough to not work properly.

    Iperf3 goes around 200 mbit/s with 8812au and 260 mbit/s with Compex VX600 (mPCI). In both cases client is Notebook with Intel 7260 dual AC stream.

@dasanchez
Copy link

@benhylau sorry I'm late to the party-

  1. I like the idea of the two pools, and the breakdown seems prudent
  2. As we order/stock items, can we keep a tally? A "tomesh_stock" folder in this repo that contains the description and location of all pooled boards and radios would be really nice.

@benhylau
Copy link
Member Author

@dcwalk @dasanchez I started this to keep track of things: #72

Allocation between Toronto Mesh vs. give out to collaborators is unspecified at the moment. @darkdrgn2k and I gave out a couple to get things moving for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ipfs-grant Supported by IPFS Research grant
Projects
None yet
Development

No branches or pull requests

6 participants