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, SPITwSPOTS
www.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]
<mailto:[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] <mailto:[email protected]> |
http://www.packetflux.com <http://www.packetflux.com/>
<http://www.linkedin.com/in/fwchristian>
<http://facebook.com/packetflux> <http://twitter.com/@packetflux>
