5 ms·
This is very interesting. I'll provide a hot take since Seam (YC S20, i.e. the company I work for) could be a target customer for this for our on-prem multi-pro
by __sy__ 5y ago
This is very interesting. I'll provide a hot take since Seam (YC S20, i.e. the company I work for) could be a target customer for this for our on-prem multi-protocol hub. There are a number of use-cases that need a cellular back-up connection.
1. The data cost of most cellular solutions out there does eliminate a number of interesting use-cases that just don't have the margins/unit-economics to swallow $10/mon of data cost. For Seam, we're currently looking at Twilio and Skywire. If this is in fact 10X cheaper, I'd want to dig into why. This may be an unpopular & contrarian opinion, but so far my take is that regular carrier networks are pretty good at what they do (network ops, real-estate placement...etc)[1]. Competing with them on pricing probably implies some important trade-offs.
2. The provisioning of a cellular modem is a bit of a PITA. AT commands can vary for each modem and makes the process a bit daunting. But if you're making a lot of units of your product like us, it's really not that big of a deal.
3. The PCI connector is interesting. I think the form factor is what makes it a non-option for Seam's Hub, mostly because it's not something we can easily plug into an existing custom PCBA. But starting with the hobbyist market, or low-scale production devices [2], is probably a good idea. They can later work their way toward modules the way most LTE modems are sort of sold today.
[1] If i am wrong, please let me know. I am genuinely curious to know where areas of operation improvements could exist in the current U.S. carrier market.
[2] This is the market that OTA as a service folks are targeting. It's much bigger than one would initially think. Example of companies in this space include Esper, Balena...etc
- rozzie 5y agoThere are no tricks to the Notecard's pricing. The 500MB/10-years of data is embedded within the hardware pricing, which is $49 for North America and $59 for 135+ countries. What's more, it's "permanent roaming" and you don't need to identify the end-user of the device. It can be used anonymously.
- __sy__ 5y agoWelp, first, thank you for taking the time to respond here. My mom won't believe it when I tell her that THE Ray Ozzie responded to my random HN comment :) Second, could you comment a bit on the latency/bandwidth of your solution? I was poking around the site and couldn't find that answer immediately available.
- rozzie 5y agoHappy to comment. We've been working on this for several years now and we're super proud of what we see people building and deploying. The question is a bit general, so let me just give you some related facts. - Because more than half our customers use this in a battery-powered way (such as a tracker), the normal operating mode (json-configured) is "normally quiescent" (~8uA draw) with the modem powered off completely. You program the sync period and can also kick off syncs manually, for example if you sense an urgent condition. - In this "periodic mode", syncs are usually take about 15 seconds to register, 1 or 2 seconds to sync, and then hanguup. If you configure for TLS it sends about 4KB for the TLS session setup, and if you don't care about on-wire encryption you can use straight TCP at about 1KB. A half dozen reasonably-sized JSON notes compresses to about 250-500 bytes on the wire. - Many customers don't use it battery-powered - such as embedding it inside an air handler or generator, etc. When in this mode, you can configure (JSON) it to be connected in a "continuous" mode. Not much downside - just a 1 packet (40 byte TCP header + 1 byte) for a ping every 20m for robustness. When in continuous mode you get "instant sync" upstream, and get a bonus feature: If you use an HTTPS (JSON) API to send an inbound message to the device, it syncs instantly to the device. - Our packets are so tiny that nobody ever thinks about actual modem bandwidth. However, you'll notice it when you're using it for firmware update. (We support DFU of modem, of our firmware, and of your own host MCU's firmware.) We have 2 primary SKUs for the product: our "Narrowband" SKUs based on BG95 which support three RATS: LTE Cat-M1 (~375Kbps), LTE Cat-NB1 (~64Kbps), and GSM (~100Kbps). For $10 more you can buy our "Wideband" SKUs based on EG91 which supports LTE Cat-1 4G/LTE, 3G, and GSM. These go up to 10Mbps. Hope you find this interesting.
- torgoguys 5y agoTerrific answer. Thanks for responding here! What kind of real world speeds are you getting on North American M1 (and NB1) networks? I know the rates that the carriers quote but see some people say to not really expect anywhere near those for these service levels. My use case would probably want to push a fair amount of data (say 1MB) very infrequently in a semi interactive mode so there would be a user waiting for the transfer to complete. Thanks!
- ohazi 5y agoIt's an M.2 key E connector, not a PCI connector, but it doesn't follow the M.2 standard -- they're just reusing a cheaply available connector. The microcontroller they're using doesn't support PCIe, so it's probably just power, some serial interfaces, and maybe some boot/reset/interrupt pins. As such, you should have far less of an issue integrating this onto a custom board than a real M.2 card that uses PCIe or USB.
- seam 5y agoah very interesting. Thank You for the correction! I quickly saw what looked like pci and some GPIO options.
- SV_BubbleTime 5y agoLooks like you communicate through that header over I2C, USB, or “serial”… which I am not sure if they mean SPI or UART/USART (or yes).
- rozzie 5y agoAll of USB, I2C, low power UART (9600 fixed), and high speed USART. They all equivalently are JSON request/response ports. I2c uses a simple serial-over-I2C protocol. Most customers use the I2C or low power UART interfaces because the device only uses ~8uA when listening on those ports. (Our internal MCU can listen on those ports while in STOP2 mode.)