1) Non-industrial temperature range. 2) Note the requirement for a SD card. 3) 2.5W power consumption vs < 1W (I sell a LOT based on this alone). 4) Product lifetime - how long are these going to be available (look at the raspberry Pi - how many revs have there been - all slightly incompatible with each other?)
and so on. This isn't a 'not invented here' type of issue. I'd love to exploit these, and although I've looked strongly at numerous options, I just haven't found any which I have felt comfortable in tying my company's future to. I've also looked at integrating the processors on these but that doesn't make sense either - you have to buy thousands to get to the cost where it makes sense - for instance, broadcom won't even talk to you unless you buy 10,000 units. That's not to say there isn't going to be a shield or two in our future. -forrest On Mon, May 18, 2015 at 11:56 PM, Josh Reynolds <[email protected]> wrote: > Honest question. > > Here's the specs on the ODROID-C1: > ----- > * Amlogic ARM® Cortex®-A5(ARMv7) 1.5Ghz quad core CPUs > * Mali™-450 MP2 GPU (OpenGL ES 2.0/1.1 enabled for Linux and Android) > * 1Gbyte DDR3 SDRAM > * Gigabit Ethernet > * 40pin GPIOs > * eMMC4.5 HS200 Flash Storage slot AND UHS-1 SDR50 MicroSD Card slot > * USB 2.0 Host x 4, USB OTG x 1, > * Infrared(IR) Receiver > * Ubuntu 14.04 or Android KitKat > Price: $35.00 > ----- > > Why aren't you just building a software stack for these that integrates > with your other products? > > Josh Reynolds > CIO, SPITwSPOTSwww.spitwspots.com > > On 05/18/2015 09:41 PM, Forrest Christian (List Account) wrote: > > There's a lot of things along those lines: > > The current sitemonitor base unit has 128KB of program memory, 3808 > *bytes* (not kb, not mb) of RAM, and an external 1MB flash storage used for > configuration and web page storage. I haven't consumed the entire 1MB > flash, but that's largely because of the other two limits, although the new > web interface might make a dent in this. > > I'm now working with a newer processor, it has 2 banks of 1MB each of > program memory (primary and secondary for firmware updates), and 512K of > RAM. The program memory can also be used for configuration and web page > storage. > > A lot of the stuff we wanted to do (traps, etc,) just didn't fit in the > older processor. The newer one obviously has a lot more room for growth - > but when you start talking about things like SNMP traps, native IPv6 stack, > https://, etc, that just need to be done, you can gobble a lot of that > memory without thinking. Then you start saying things like "system logs", > "historical graphs", "firmware files", etc., and all of a sudden that 1MB > isn't enough. So, you need some additional storage. With a SD card, 4GB > is enough that in this application you could think 'essentially > limitless'. Which is how I got to this question. > > Just to be clear, I have a different product (than a base 3) which we're > close to releasing. In fact, we had hoped to get it out the door by the > end of June, but I think this will slip a bit. I figured I'd rather put > this new processor in something a bit less risky and a bit lower volume > than the base 3 until we had some experience with it. If it works well, it > will form the basis for the next iteration of network-connected PacketFlux > products. If not, we might be looking for something different, although it > will be hard to find something with the power consumption limits I've > placed on it. > > -forrest > > On Mon, May 18, 2015 at 10:36 PM, George Skorup <[email protected]> wrote: > >> Yeah, that could be useful. But why not just store stuff like this in >> RAM? Perfect example is the throughput monitoring statistics on Canopy. It >> obviously doesn't persist across reboots. I know you probably don't have a >> lot of RAM to work with though. >> >> Let me give you another example pertaining to the SiteMonitor in >> particular. If I could have a log of the sync pulse status on a >> SyncInjector for the last 15 minutes (or 30 minutes, or an hour).. on a 1 >> or 2 second interval, I could prove to Cambium that their code is broken on >> the 3.6 450 and it is NOT the SyncInjector. I already know it's not the >> SyncInjectors, and it's not the SyncPipes either. But I wouldn't need this >> stored permanently. In RAM is good enough. I just can't/don't want to do >> SNMP polling of the SiteMonitor every second or two, or five. And 10 >> seconds is too long, 5 minutes is definitely too long. >> >> But for something such as this, you could send an SNMP trap (I know, I >> know) when the 1PPS active value goes to zero, almost instantly. Just >> sayin. >> >> >> On 5/18/2015 10:52 PM, Forrest Christian (List Account) wrote: >> >>> More applicable to the current design, there's been some requests for >>> on-device logging of enough data so that certain values would have >>> historical graphs >>> >> >> > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > [email protected] | http://www.packetflux.com > <http://www.linkedin.com/in/fwchristian> > <http://facebook.com/packetflux> <http://twitter.com/@packetflux> > > > -- *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 [email protected] | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
