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>
