A lot of the reason why it took us so long to get even started on the rackinjector was trying to find a way to do what everyone knows they want, and what I'd like to sell. Which is largely the items which keep coming up, specifically the front side swappable cards and the software configuration.
We looked at front side changeable. In order to do that at the volumes we were talking about, just the chassis would have been around $250 in reasonable quantities. No electronics other than the chassis, and a passive backplane card. And there was the whole mismatch between what we thought a reasonable quantity was and what the enclosure manufacturer thought was a reasonable quantity, so we would have been forced to buy (based on current rackinjector shipping volumes) around 2-3 years worth upfront of the chassis to make this work. In relation to the software configurable issue, it's a lot of the same thing: If you take every single possible jumper position and add a software switch, you need to add somewhere between $1-2 per jumper of electronics cost. By the time you get it on the board you have to figure about $2-4 per jumper. A single port on a powerinjector has 11 jumper positions, so $22-$44 added cost per port. Then there's the space, so you'd probably need a bigger board and/or a double sided load or multiple stacked boards to fit it all on. Generally you're now looking at a 4 port board which is easily $200 more expensive. Would you pay $350 for a 4 port port injection card, and then still have to pay for a chassis and control board? Probably not. And the level of engineering on this board would require us to sell thousands before we got a return on investment, which isn't likely based on the cost. Not to factor in that the first port-configuration software bug would likely cost us lots more in paying for radios we cooked. I am *absolutely* not saying that this isn't going to happen. I continue to spend a few hours every once in a while trying to crack this nut and get the costs down. There are ways to do it on the cheap but then you end up with ports which fall over during the slightest provocation. Although I try very hard not to overengineer things, I also refuse to ship a product which won't survive most common fault conditions. We also looked at putting a DC-DC converter on each port to provide individually settable power. Back when radios were 7W/each that was doable. Now they're 50+ watts, not so much. The whole need for different configurations for radios is going away anyways. Almost every modern shipping radio today needs 48V and is polarity agnostic. If you see 802.3af or 802.3at or similar, that means you're pretty much guaranteed that it will handle 48V and the polarity doesn't care. The jumpers are there to support older radios which need something other than 48V on some reasonably standard set of pins. In the cambium world, this pretty much is confined to the 450 and earlier radios, and a few newer SM's. You could set all of the jumpers in the rackinjector to power a 450i and pretty much any modern AP will receive power just fine off of it. The higher power radios (medusa, airfiber, etc), would need all 4 pairs jumpered, but there again, all modern 4 pair powered radios will work off of this. In fact, most 2 pair powered radios will work off of it as well. On Thu, Dec 21, 2017 at 3:06 PM, Darren Shea <darr...@ecpi.com> wrote: > Well, I certainly understand that cheap and flexible tend to be opposites, > which is why I would think the best way to do what I suggested would be to > make the module a pricier option, not a default. A multi-purpose tool has > the potential to be more useful to a wider range of people than something > which is practically a uni-tasker. Having to shut off all the APs on a > RackInjector to replace one is not fun – having to perform surgery on a > deployed RackInjector while 7 fully-functional APs have to be shut off > during the process is even less so. > > > > Even as an internal add-on card with a bunch of cables to each of the > jumper blocks could be a major factor in deciding how to build-out a new > site. Front-swappable might also work (maybe each card could be in a > drawer-like setting with a front-accessible screw or two to lock it down > most of the time) if we’re keeping the jumpers for cost. Just brainstorming… > > > > > > *From:* Af [mailto:af-boun...@afmug.com] *On Behalf Of *George Skorup > *Sent:* Thursday, December 21, 2017 3:32 PM > *To:* af@afmug.com > *Subject:* Re: [AFMUG] Remote generator start options packetflux? > > > > Do you want PacketFlux injectors to cost what CMMs and CTMs do? No. And > neither does Forrest. > > We've done several radio swaps year after year. I take a spare > SyncInjector/PowerInjector/RackInjector/whatever and swap it. > > Yes, it would have been cool to see the cards for the RackInjector be > easily front swappable like storage on a server. Again, complexity and cost. > > On 12/21/2017 2:40 PM, Darren Shea wrote: > > Forrest, > > That’s really interesting – am I jumping to conclusions, or does that > modular design of the underlying architecture mean it would be possible to > design a module which would replace the jumper options on the current > RackInjector with a fully controllable, web-accessible, interface? > Honestly, that’s the only reason we haven’t deployed ours – the fact we are > mixing PMP450 and 450i/450m APs and ePMP 1000 and 2000 APs means that > having to partially disassemble the RackInjector to change an AP is a > statistically likely and pretty daunting task. Having a module to give the > programmable flexibility of a LMG CTM-2M, for instance, without having to > remove the unit from the rack, open up the case, and move around jumpers > when switching AP types would be a big thing… > > > > Thanks, > > n Darren > > > > *From:* Af [mailto:af-boun...@afmug.com <af-boun...@afmug.com>] *On > Behalf Of *Forrest Christian (List Account) > *Sent:* Thursday, December 21, 2017 9:57 AM > *To:* af > *Subject:* Re: [AFMUG] Remote generator start options packetflux? > > > > I'd like to explain where we are in the grand scheme of things. Getting > the rackinjector out the door took pretty much all of our R&D engineering > for the last year or so. BUT... there's a reason for this, and it is > related to the technology which is underpinning the web interface on that > device. And which is related to our fairly near-term future as far as > packetflux goes... > > > > The architecture underneath the rackinjector control system is far more > layered and abstracted than it would need to be to provide just the web > interface. Every piece of data is abstracted into a generic data format > inside the unit, and the system is designed in a way to greatly simplify > the addition of additional features. The overriding idea is an on-site > system which is able to gather up status from the entire site and also be > able to control an entire site. > > > > To sort of give you a glimpse, in the rackinjector, there is a module for > gathering up data from a NMEA GPS stream (GPS lock status, etc), a separate > module for measuring the timing of the PPS pulses, a separate module for > the analog digital controllers, another module to pull data from > sitemonitor expansions (the expansion cards in the rackinjector are running > the same underlying protocol as the sitemonitor expansion cards are today), > and so on. Each of these modules pull data from their information source > and makes it available in a generic manner to the system. For instance, > the number of satellites in view is accessed in exactly the same way > internally as a voltage reading. This abstraction allows me to add > additional modules to pull data quickly - all I have to do is to create a > chunk of code to pull data from say a solar charge controller or pull > values via SNMP from a radio. The difficulty varies of course based on > how hard it is to access the data, but it's a lot easier than writing an > entire stack for each device. > > > > Today the rackinjector is running what we call internally the > "DeviceManager" code on top of this. Generally what this is is a > purpose-built web interface which is built on the underlying architecture. > The web-interface actually pulls the data it needs from the underlying > system using another generic chunk of code so it is relatively easy for us > to add additional fields and support for additional devices. The > "DeviceManager SNMP" module allows quick development of SNMP mibs again for > specific purpose appliances. There's a few other tricks coming as well. > Our intent with this code base is to build a set of specific-purpose > appliances to pull data largely from one device or a couple of devices and > provide it in a simplified manner to the user. For instance a Solar > Charge controller monitor. Or a RackInjector controller. The key point > here is that the DeviceManager codebase is designed largely to hide all of > this from the end-user, while making it easy for us to build these products > quickly. > > > > Now, back to the main point: This same flexible architecture permits us > to also build various automated control systems on top of the same > underlying architecture. If you replace the fixed-function devicemanager > interface with a programmable, scriptable, flexible interface, all sorts of > things start to happen. Including all of the items we're discussing in > this thread. We already sell all of the physical interfaces needed to get > a generator controller running - you can plug a unregulated power supply > into a voltage input to get a rough idea of the AC voltage, or can get the > DC voltage using another voltage input. You have contact closures in the > form of another sitemonitor expansion module. And so on. What is > missing is some sort of on-site automation, and that's where we've been > heading with this entire architecture for about 2 years now. > > > > I don't know how quickly this is going to happen. The next 30 days I'm > focused on 'finishing' the rackinjector - meaning shipping the cambium sync > cards and the new 'either polarity' cards, and getting a new firmware out > for it which has the "Devicemanager SNMP" code running in it. Once that > is done we can re-focus on how to prioritize the future of this > architecture. > > > > > > > > On Thu, Dec 21, 2017 at 7:40 AM, Dave <dmilho...@wletc.com> wrote: > > Forrest, > We had a discussion about this as we now have 4 generators and I have 3 > of your standby controllers taking care of > these sites without issue since we installed them. > Would it be feasible to just remove the Transformers and just give a link > for separate purchase ? > My issue as with many would like to see a box with many inputs to monitor > different things like AC,DC voltages, tempatures > make and brake contacts. Also, the need for active outputs to turn on off > things or just for a cycle with timer. > A nice gui would be ok to be able to log in for manual control or > configuration. > > There are some very expensive things out there to do all of this but I > know with a little work it can be done with out much money involved. > > I have a very specific need to integrate a 26vDC generator with a site > that is a 48v plant. I have everything installed and connected but I need > some > automation to start and stop when needed. > The generator has a voltage sense on its output to detect if the battery > bank is below 22vdc and if so it will kick on for an amount of time to > restore > charge. The problem with this is there is a 1000W converter between it and > the 48v battery bank. > > Anyone with suggestions is welcome > Dave > > > On 12/21/2017 03:18 AM, Forrest Christian (List Account) wrote: > > The short version: I never sold that many, and this particular product > came up in discussions about product liablity insurance. Not that it was > unsafe, just that there was some discomfort with the fact that I was > monitoring the AC power line. To remedy this I would have either had to > redesign to remove the AC monitoring hardware, or send the whole thing > through UL listing. Based on the volume, I didn't really see any reason > to spend a lot of R&D time or money doing either. > > > > I do expect the functionality in the generator controller will be able to > be replicated as a side effect of planned technology to be incorporated in > an upcoming product. > > > > > > On Wed, Dec 20, 2017 at 8:23 PM, Lewis Bergman <lewis.berg...@gmail.com> > wrote: > > Bummer. Guess there was not enough demand or to make variants? > > > > On Wed, Dec 20, 2017, 5:18 PM George Skorup <george.sko...@cbcast.com> > wrote: > > Yeahbut Forrest doesn't make the generator control board anymore. > > > > On 12/20/2017 5:01 PM, Lewis Bergman wrote: > > I think packetflux is likely the easiest with the most to offer our of the > box. I know if one other out of the box solution that cost about 3 times as > much. First can not only start it but he can use his shunt to make sure it > is actually started and producing current. > > If you want to do it yourself you could work some coding and such but it > doesn't sound like that is what you want to do. Arduino, raspberry pi, etc. > Could do this but you have to build it all yourself. Not really fast but > fun if you like that kind of thing. > > You would need some electronics knowledge if you don't want to spend a few > days googling. I guess you still have to know enough to make Google work. > > Again, see Forest for his genset setup. I know a lot of people in this > list use it. > > > > On Wed, Dec 20, 2017, 4:39 PM Eric Kuhnke <eric.kuh...@gmail.com> wrote: > > assuming you have a generator that does auto-choke and is wired for > electrical remote start, like the small generac units sold for RV use and > similar... where all you need to do is turn on a relay for 4-5 seconds to > crank a starter, then turn off the relay again. > > > > one of these: http://tinycontrol.pl/en/lan-controller/ > > > > and one of these: http://tinycontrol.pl/en/relays-board-10a-v3/ > > > > or a thing like this: http://denkovi.com/ethernet-relay-card-5- > channels-snmp-http-xml-real-time-clock-din-box > > > > > > there are quite a few different DIN mount relay-controllers with basic > http interfaces to turn on and off things. Some support things like > receiving an snmp trap to trigger a relay for automated scripting. > > > > On Wed, Dec 20, 2017 at 2:30 PM, Brandon Yuchasz <li...@gogebicrange.net> > wrote: > > We are looking at adding a remote start to a generator at an off grid site > we have and I am gathering information on options at this point. > > > > Right now we are all Solar at the site. It’s a new site and if / when we > draw down batteries beyond where we are comfortable we turn go to the site > turn off the PV and start a generator manually and run a 48v battery > charger on the bank. It’s a fairly low tech solution right now. We log in > turn off the PV array and a guy goes out and pulls the rope on the > generator and batteries start to charge. He then leaves and in three hours > generator runs out of fuel and charging stops. Log back in turn the PV back > on and that’s the end of the process. > > > > We are considering a few different options at the site and I don’t want to > complicate this to much by offering to much information to start. Ill go > into more details later but for now I am looking for a way to start a > (different) propane generator remotely during the dark months. Most likely > once a week in December and January. > > > > So assuming electric start is an options on the generator. What options do > I have for throwing that “switch” from the office. I am positive I am not > the first one of us to want to do this. > > > > Thoughts everyone? I want to KISS so when I am not around others can do > this with minimal training. > > > > Thanks, > > Brandon > > > > > > > > > > > > -- > > *Forrest Christian* *CEO, PacketFlux Technologies, Inc.* > > Tel: 406-449-3345 <(406)%20449-3345> | Address: 3577 Countryside Road, > Helena, MT 59602 > <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> > > forre...@imach.com | 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 <(406)%20449-3345> | Address: 3577 Countryside Road, > Helena, MT 59602 > <https://maps.google.com/?q=3577+Countryside+Road,+Helena,+MT+59602&entry=gmail&source=g> > > forre...@imach.com | 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 forre...@imach.com | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
