Live data from Hacker News

Taking over a Dead IoT Company

blog.kchung.co

31–40 of 213 posts

Re: Taking over a Dead IoT Company

#31
post #25

Earlier quoted context omitted.

Just curious what made you come up with at least $30 per LED panel, as these should run you about $10 in bulk.

I had found some tweets by the company where they talked about using an Adafruit panel that was $40. The price on Amazon was about $30 so I figured I would go with the lower price. They may have switched to a lower cost panel but my guess is that didn't happen. EDIT: Here is the specific tweet: https://twitter.com/NYCTRAINSIGN/status/926106932573810688

The generic name for these panels are "HUB75", based on the interface they use for driving them. I can confirm, these are $10-15/ea in small quantities on sites like Aliexpress. But you're likely right, they were probably buying retail from Adafruit.

Re: Taking over a Dead IoT Company

#32

Earlier quoted context omitted.

I think dunking on the rpi is harsh - if it allows you to prototype and get your small-volume product out the door quickly, there's lots of other areas you could optimize the BOM first. Better to make a product with 75% gross margins as a single dev in 6 months than a product with 80% gross margins with a team of 6 in a year. Of course, they also overhired and wasted money on other BOM components

If your product needs to output HDMI, I can easily see an argument for using a Pi. If your product needs a couple GPIOs to drive an LED matrix? Using an RPi is pretty difficult to justify. You're likely going to spend more on the SD card for the Pi than you would on more suitable microcontroller (which can still be easily programmed and, in my experience, has a better [or at least no worse] story for GPIOs than the P…

It's difficult to drive these LED matrix devices from a typical MCU, especially with chained panels, lots of LEDS, etc. Either due to the ~10Mhz+ output needed, or the memory to hold all the pixel data. Consider, for example, that each of the two panels in this sign has 32x64X3 (6144) leds. You have to send on/off for all of those, and then control brightness for each color by using PWM...meaning half-red brightness would be changing that pixel so it's on/off/on/off fast enough to beat persistence of vision.

It's more common in the pre-built devices to have a controller that's using a main CPU plus a FPGA or CPLD. The better hobbyist drivers use things like a beaglebone black and it's onboard "PRU" that can drive real time from memory it shares with the ARM cpu and Linux.

Also, since it's pulling train data, you need more smarts or cycles than a typical MCU to pull via WiFi/https, transform text into pixmaps, etc. Though there are examples of beefy MCUs doing all this well, like an ESP32. Or examples of small MCUs driving a small single color matrix.

Re: Taking over a Dead IoT Company

#33
post #22

Towards the end of the article the author mentions not wanting to pursue this as a business as there are so many cheap programmable signs out there already. As someone who would love to buy one of these and customize it for myself does anyone have experience or recommendations with any of these?

Some experience. The cheapest and easiest route is to buy a pre-made sign from AliExpress and just use the serial/usb interface to send data to the sign. That's somewhat limited, as you can't really control each pixel in a real time way, and you're limited to sending a series of "screens" as either text (in their limited choices of fonts) or images, defining some linger time, transitions, etc. With some visual disrup…

Did you intentionally leave out Arduino from the "what to drive with" options?

Re: Taking over a Dead IoT Company

#35

Earlier quoted context omitted.

I had found some tweets by the company where they talked about using an Adafruit panel that was $40. The price on Amazon was about $30 so I figured I would go with the lower price. They may have switched to a lower cost panel but my guess is that didn't happen. EDIT: Here is the specific tweet: https://twitter.com/NYCTRAINSIGN/status/926106932573810688

The generic name for these panels are "HUB75", based on the interface they use for driving them. I can confirm, these are $10-15/ea in small quantities on sites like Aliexpress. But you're likely right, they were probably buying retail from Adafruit.

Why would you buy retail if you are a company buolding and selling hardware to begin with?

Re: Taking over a Dead IoT Company

#36
post #22

Earlier quoted context omitted.

Some experience. The cheapest and easiest route is to buy a pre-made sign from AliExpress and just use the serial/usb interface to send data to the sign. That's somewhat limited, as you can't really control each pixel in a real time way, and you're limited to sending a series of "screens" as either text (in their limited choices of fonts) or images, defining some linger time, transitions, etc. With some visual disrup…

Did you intentionally leave out Arduino from the "what to drive with" options?

Assuming largish, multi-color matrixes, and/or chained ones, yes. A ~10Mhz+ pixel clock, double-buffering, or just the size of the pixel map would strain most of those. This sign is 32x128 pixels, with each pixel taking data for RGB (on/off), with the PWM rate controlling brightness for each of the three colors. Though there are examples of using something beefier/faster like an ESP32. There's also in this case, the assumed requirement of fetching train data and transforming text into pixels.

The panels themselves don't take data and hold it. You have to refresh the display constantly, typically on a 1/8 or 1/4 duty cycle.

You can drive smallish, single color matrix displays with a cheap MCU. Or there's also the approach of using addressable LEDs instead of these more "dumb" matrix modules, like arranging the smart strips into a matrix. Moves the refresh logic down into each LED.

Re: Taking over a Dead IoT Company

#38
> With full control of the domain, we can create a new API based on what the sign is expecting and revive all of the signs that are out in the field.

Once the new server was up, did any signs from the field connect to it?

Re: Taking over a Dead IoT Company

#39
post #24

Earlier quoted context omitted.

I think dunking on the rpi is harsh - if it allows you to prototype and get your small-volume product out the door quickly, there's lots of other areas you could optimize the BOM first. Better to make a product with 75% gross margins as a single dev in 6 months than a product with 80% gross margins with a team of 6 in a year. Of course, they also overhired and wasted money on other BOM components

The problem with rPi is storage and filesystem. You need to issue a shutdown command and wait for it to complete before removing power in order to help ensure that it will come up without problems. This will literally never happen with a consumer IoT device. Also, SD media is extremely prone to failure. It's fine for prototype at a very early stage, absolutely not fine for something you ship to a user.

On the other hand, see https://news.ycombinator.com/item?id=33892009, https://www.raspberrypi.com/success-stories/korg-synthesizer... for example on how some companies use Raspberry Pi compute modules in their products.

Am assuming here that they're adopting strategies to minimize/work around the problems you mention.

Re: Taking over a Dead IoT Company

#40
Articles like this are part of why I love Hacker News so much. I've done a little investigation into producing hardware myself and concluded it was just too big a task for someone without the background who didn't want to put up a ton of capital or deal with overseas manufacturing. I loved reading this.
Post reply on HN