<daveshah> *spi clock
<cr1901_modern> where do you get half from?
<daveshah> Well, with C each instruction is 16 bits
<daveshah> That said picorv32 isn't single cycle anyway so it should be fine
<cr1901_modern> oh compressed insns aren't supported in migen yet (afaik(
<daveshah> Ah
<daveshah> That's quite important if running of spi flash
<azonenberg_work> wbraun: you can use some 0.8mm parts on oshpark
<azonenberg_work> but you do lose some pins
<azonenberg_work> and it only works with smaller ball diameters, i think 0.4mm balls are OK but 0.5 are not
<whitequark> you can also stretch the board house specs
<whitequark> a bit
<azonenberg_work> eh, my experience is that oshpark's annular ring is already really tight
<whitequark> hmm ok
<azonenberg_work> you get close to breakout frequently
Bob_Dole has joined ##openfpga
<azonenberg_work> i wouldnt make that any smaller
<azonenberg_work> in fact, to reduce the chance of yield issues i use bigger-than-minimum rings most of the time
<azonenberg_work> then i use minimum only when i can't fit anything else
<wbraun> the lattice docs talk about 0.35mm balls and 0.4mm balls. With 0.4mm balls I could not route between balls with min space/trace
<wbraun> I could escape things to the bottom of the board though.
<wbraun> Someone told me about jlcpcb though which has better space/trace and minimum via/anular ring than oshpark while maintaining the cheap chinese board house price structure. So its not that big a deal anymore.
knielsen has joined ##openfpga
<cr1901_modern> azonenberg_work: >but 0.5 are not <-- is this solely due to clearance issues for routing when using appropriately-sized pads?
<cr1901_modern> or also because of breakout?
<azonenberg_work> cr1901_modern: iirc, with bigger balls you could not fit vias between the lands
<azonenberg_work> so you could only fan out the outer ring of balls and maybe one ring inside
<azonenberg_work> on the top layer
<gruetzkopf> yeah i've semi-accidentally pushed jlcpcb to 3.5/4
<gruetzkopf> VIP prices need to come down
<cr1901_modern> azonenberg_work: *nods* I know you don't like it, but what about via-in-pad?
<wbraun> jlcpcb claims that 3.5/3.5 is the standard spec for anything with 4 layers or more.
<wbraun> and 0.45mm via diameter.
<wbraun> Given that they also have very cheap 6L board prices I am eager to try them out.
<gruetzkopf> i could do with less via dia
<gruetzkopf> i believe them on 3.5
<wbraun> I am working on using FPGAs for some power electronics control applications. I think my first rev is going to use a 1mm pitch xilinx FPGA to limit risk but my eventual goal is to use the ecp5 FPGAs with the open source toolchain.
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/73b0451c261c24a32e082ea50e123e0669ab995f
<openfpga-github> Glasgow/master 73b0451 whitequark: protocol.jtag_svf: new protocol.
<travis-ci> whitequark/Glasgow#139 (master - 73b0451 : whitequark): The build has errored.
<azonenberg_work> cr1901_modern: i love via-in-pad
<azonenberg_work> i use it whenever somebody else is paying for the pcb :p
<azonenberg_work> Or do you mean UNFILLED via-in-pad?
<azonenberg_work> because that's an absolute no-no
<azonenberg_work> Filled ViP is awesome, it's just not cheap
<gruetzkopf> it needs to become cheap
<azonenberg_work> sure, so does 8 layer HDI
<azonenberg_work> lol
<cr1901_modern> Idk the difference
<azonenberg_work> cr1901_modern: if you drill the via, then fill it with epoxy and plate copper over the top, the via is invisible from the surface
<azonenberg_work> there's sometimes a tiny dimple in the top a few um thick but that's it
<azonenberg_work> it just looks like a bga pad
<cr1901_modern> ahhh
<azonenberg_work> You can put these vias under components with no problem and they act just like there was no via there
<cr1901_modern> I prob meant unfilled
<azonenberg_work> But it's an extra process step, batch fabs don't do it
<azonenberg_work> real fabs can do it but charge extra
<azonenberg_work> (generally $100+ setup fee plus a decent amount more per board if memory serves me right)
<azonenberg_work> unfilled ViP is a horrible idea
<sorear> What do you accomplish by drilling a hole and then immediately filling it with nonconductive material?
<azonenberg_work> sorear: you drill the hole, plate the sidewalls, then fill it
<azonenberg_work> so there's a conductive path but the center is filled and solder can't wick down
<azonenberg_work> (You can also fill with conductive epoxy, but this is less common)
<azonenberg_work> anyway, vias in big SMT pads suck solder down and lead to voids etc
<azonenberg_work> vias in BGA pads are even worse because you have so little solder available
<azonenberg_work> the entire bga ball often sucks down into the hole leaving an open connection
<whitequark> lewd
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/a08dd2b9bc452a419f994a6b81c3a3e2634d44a1
<openfpga-github> Glasgow/master a08dd2b whitequark: applet.jtag.svf: new applet.
<whitequark> azonenberg_work: yep works
<travis-ci> whitequark/Glasgow#140 (master - a08dd2b : whitequark): The build has errored.
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 264 seconds]
[X-Scale] is now known as X-Scale
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
lovepon has quit [Ping timeout: 250 seconds]
rvense has quit [Ping timeout: 240 seconds]
unixb0y has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
Bob_Dole has quit [Remote host closed the connection]
* sorear isn't quite sure what you'd use a GSR *primitive* for
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
Bob_Dole has joined ##openfpga
jevinskie has quit [Quit: Textual IRC Client: www.textualapp.com]
rvense has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
lovepon has joined ##openfpga
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
azonenberg_work has joined ##openfpga
Miyu has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
<openfpga-github> [libfx2] whitequark pushed 1 new commit to master: https://github.com/whitequark/libfx2/commit/945f36cf6a1f633250a472f890323a5455ddf4a1
<openfpga-github> libfx2/master 945f36c whitequark: Split UF2 code into a reusable `fx2uf2` library.
Bike has quit [Quit: Lost terminal]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<azonenberg_work> sorear: you use it to write the global set/reset line combinatorially from an external signal source
<azonenberg_work> If you want to soft reboot the chip
<azonenberg_work> this isnt too useful in a modern design because it wont wipe lutram or block ram, so you dont get quite a clean slate
rohitksingh_ has joined ##openfpga
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh_ has quit [Ping timeout: 240 seconds]
<sorear> I guess somebody must have had a design where this was useful, having a bit of trouble imagining what it would have looked like
rohitksingh_work has joined ##openfpga
s_frit has quit [Read error: Connection reset by peer]
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
tms_ has joined ##openfpga
tms_ has left ##openfpga [##openfpga]
m4ssi has joined ##openfpga
rohitksingh_work has joined ##openfpga
<keesj> omg tomu FPGA
lovepon has quit [Ping timeout: 250 seconds]
<daveshah> sorear: Diamond for ECP5 will also promote the highest fanout reset signal to GSR (it does support sync or async reset) by default
<daveshah> This does save a global network network
<azonenberg_work> daveshah: so GSR isnt truly global then?
<azonenberg_work> in xilinx land, GSR is not opt-in
* sorear noticed the GSR work in the trellis changelog
<azonenberg_work> it's literally every DFF on the chip (for FPGAs at least)
<azonenberg_work> (conversely for xilinx CPLDs it's just a high fanout net you can use or not use freely)
<daveshah> azonenberg_work: every primitive in the ecp5 with storage has a GSR disable config bit
<azonenberg_work> modern xilinx tools will use BUFG's for high fanout resets
<daveshah> I believe Diamond will too if they are very high fanout and GSR already used or disabled in the setting
<daveshah> The ecp5 gsr cell also has a clock input as well as gsr for an optional sync reset mode
<sorear> are you planning to use it for something? :)
<daveshah> No, just wanted it in there for completeness sake
<daveshah> At the moment Yosys inferred flip flops have GSR set to disabled anyway
<daveshah> That probably is best as a setting
<azonenberg_work> daveshah: i would detect the highest fanout reset and infer a GSR for that
<azonenberg_work> (assuming GSR is something you can write from fabric and not a dedicated input pin like it is on the CPLDs)
<daveshah> Yes, that's the long term plan
<daveshah> It's just driven from fabric
<daveshah> From a CIB (generic interface tile) in Lattice parlance
<sorear> so I was confusing GSR with PUR
<azonenberg_work> sorear: yeah in xilinx FPGAs, GSR is the net asserted chip-wide during POR/bitstream loading
<azonenberg_work> and you cant opt out because they want to make sure every dff starts in a predictable state
<azonenberg_work> i think they only made it runtime writable for debugging, then kept because somebody found it useful :p
grantsmith has quit [Quit: ZNC - http://znc.in]
grantsmith has joined ##openfpga
<daveshah> azonenberg_work: Something interesting is that ECP5 DFFs don't have a programmable init value, but init to their reset state (so 1 if set or 0 if reset)
<azonenberg_work> yeah i've seen stuff like that
<azonenberg_work> i've also seen dff's that only have a reset
<azonenberg_work> and to initialize to 1, you put an inverter before and after :p
<daveshah> I believe this is because GSR, which is always asserted at power up, is ordered with local set/reset
<daveshah> Also curious is that set/reset ignores clock enable even when synchronous
<daveshah> This required a change to Yosys to deal with
<azonenberg_work> huh interesting
<daveshah> Heh, the best way to learn an FPGA is definitely to document its bitstream
<azonenberg_work> imo you havent truly learned a chip inside and out until you've found bugs in the datasheet
<azonenberg_work> and/or implemented a cycle accurate verilog model of it :p
wbraun has quit [Quit: wbraun]
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
Mimoja has quit [Quit: Ping timeout (120 seconds)]
GuzTech has joined ##openfpga
Bike has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
Miyu has joined ##openfpga
GuzTech has quit [Quit: Leaving]
<kc8apf> I'm back to writing parsers. Starting with BLIF while I learn tree-sitter. https://github.com/gaffe-logic/tree-sitter-blif
<kc8apf> if you have BLIFs with interesting constructs, please send a PR to add them to the test corpus.
<daveshah> kc8apf: awesome
<daveshah> are you planning on adding the Yosys (and VPR) eblif constructs (attr, param, etc)
<kc8apf> yes
<kc8apf> as runtime selectable options
<kc8apf> I want a strict BLIF parser and an eBLIF parser
<daveshah> sounds like the best way forward
<kc8apf> writing tests with tree-sitter are so much simpler than every other parser generator I've tried
<sorear> how is it with error message generation?
<kc8apf> so the test results are s-expressions. When I've caused parse errors, it generates ERROR nodes in the tree
<kc8apf> I don't think it tell you what the possible options are
<kc8apf> but it's also intended to just get you an CST & AST
<sorear> i'm trying to make something that produces high-effort error messages, and there don't seem to be great options
<kc8apf> well, you'll know where in the parse tree the error was encountered and what input range caused the error
<kc8apf> it just doesn't tell you what the valid options were at that point
wbraun has joined ##openfpga
mumptai has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
m4ssi has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
wbraun has quit [Quit: wbraun]
wbraun has joined ##openfpga
<SolraBizna> someone try to hilight me
<Richard_Simmons> SolraBizna,
<SolraBizna> yeah, I definitely broke my hilight
<qu1j0t3> restart
<Richard_Simmons> restarting doesn't fix configuration errors. fixing configuration errors fixes configuration errors.
<qu1j0t3> TIL
<qu1j0t3> i was joking fwiw
wbraun has quit [Quit: wbraun]
<SolraBizna> I was trying to make it so that this channel won't beep me (while the channels I moderate still will)
<SolraBizna> instead I made it so that this channel won't notify me ever
wbraun has joined ##openfpga
<openfpga-github> [libfx2] whitequark pushed 2 new commits to master: https://github.com/whitequark/libfx2/compare/945f36cf6a1f...21264788fab5
<openfpga-github> libfx2/master 2126478 whitequark: Change usb_descriptor_set layout to support functional descriptors.
<openfpga-github> libfx2/master 4a0eb5a whitequark: Document the UF2 library.
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
mumptai has quit [Remote host closed the connection]
<balrog> it looks like rapidwright returned?
<daveshah> balrog: yup it came back a few weeks ago
<daveshah> All the good bits obfuscated now :(
<balrog> daveshah: ugh :(
<daveshah> Pretty sure mmicko found at least one class you actually needed broken by the obfuscation
<balrog> "RapidWright API Library is composed of two groups of compiled Java class files"
<balrog> yeah, looks like it's all obfuscated
<balrog> and under restrictive EULA
<whitequark> so, does anyone have a copy of the old rapidwright?
<balrog> the code or the data?
<whitequark> either
<azonenberg_work> rapidwright is dead to me at this point, xilinx has demonstrated they dont really care about it
<azonenberg_work> (they wont support designs using it etc)
<azonenberg_work> they already half-killed it
<azonenberg_work> tl;dr rapidwright gives up all of the benefits of the proprietary xilinx toolchain
<azonenberg_work> But none of the benefits of an open one
<daveshah> Also it lacks timing data which makes it useless for any serious PnR type stuff
<azonenberg_work> Yeah
<balrog> then what's the point?
<daveshah> Even XRay is working on timing now :D
<balrog> (and why all the obfuscation?)
<SolraBizna> "THEY'RE GONNA STEAL OUR SECRETS~"
<daveshah> My understanding of rapidwright is some individuals inside xilinx want to work towards much more openness
<azonenberg_work> and management is coming down on them?
<daveshah> Yep
<azonenberg_work> Well it's gonna get opened up with or without them
<daveshah> Indeed
<azonenberg_work> If they released a good toolchain and fully supported it, including full query access to timing data for every path etc
<azonenberg_work> a good bitstream library*
<azonenberg_work> then there would be a lot less people working on xray
<azonenberg_work> because most people wouldnt need it
<daveshah> yeah
<azonenberg_work> as it stands, there's demand
<daveshah> fpga companies are weirdly cagey about timing data
<daveshah> Even though its silly I can sort of understand the bitstream stuff
<daveshah> But what does timing data really give way?
<balrog> they don't want people to think their chips are not as good as they claim :p
<azonenberg_work> lol
<daveshah> I almost wonder if it's a crazy knock on effect of fab pdk ndas
<whitequark> huh
<daveshah> I think some fpga tools do use quite low level resistance and capacitance models for their interconnect timing models
<daveshah> istr Intel boasting that Quartus used a special circuit simulator as part of timing analysis
<azonenberg_work> daveshah: i dont see why r-c data matters at this level
<azonenberg_work> unless you have pass transistors without buffers, where the speed can depend on the number of loads or something
<azonenberg_work> if every pip is a buffer then you can treat each delay as a unit
<daveshah> ecp5 has fully buffered pips, but their structure means each turned on pip adds some delay
<daveshah> About 10ps per pip loading down a net
<daveshah> I think 7 series might use a fancier model
<azonenberg_work> so in ecp5, turning on pips increases load on the driving net?
<daveshah> yes
<azonenberg_work> it's not a flat "everything drives everything and we either ignore or use the result"
<azonenberg_work> interesting
<daveshah> The structure of each routing mux is a cascade of transistors selecting the input to a buffer
<daveshah> Clearly the input capacitance of the buffer is non negligible
<azonenberg_work> yeah
<azonenberg_work> i assumed that they'd have a buffered mux2 cell right at the end
<azonenberg_work> and thus you always were driving that mux
<azonenberg_work> so downstream cap was irrelevant
<azonenberg_work> but i guess that matches more with the coolrunner architecture where you do increase loading as you turn on pass transistors
<azonenberg_work> you know, i should try measuring that
<azonenberg_work> if i enable ZIA row drivers reading from a given column, does the column output get slower?
<daveshah> Crude but official schematic
m4ssi has joined ##openfpga
<azonenberg_work> ah ok
<azonenberg_work> so predriver input cap is probably what gets you
<daveshah> Yup
egg|egg is now known as egg|zzz|egg
<daveshah> About 10ps per load with a typical span 2 wire being about 150ps
<daveshah> So in a theoretical worst case scenario with 16 loads, IIRC the maximum for span2 wires, it would double your wire delay
<daveshah> Although I don't see that as likely to happen
<daveshah> I need to experiment more for the case where loads are split between different tiles
<azonenberg_work> this is very interesting, i just kinda assumed that fpga wires were all fully buffered
<azonenberg_work> and thus you had a large, but constant ,delay for a given span
<daveshah> No, I think Xilinx is similar too
<azonenberg_work> is this based on diamond timing numbers?
<azonenberg_work> or measured performance?
<daveshah> Diamond, haven't attempted any measurement yet
<azonenberg_work> would be fun to make a ring oscillator and watch the speed drop as you add loads to the path
<azonenberg_work> lol
<daveshah> Yeah, that sounds like a fun experiment
<azonenberg_work> i have a lot of fun ideas for stuff to do once i'm moved into the new lab lol
<azonenberg_work> But right now having walls and ceilings matters more :p
<SolraBizna> ceilings are overrated
<SolraBizna> get bonus cooling during rainy weather
<daveshah> Should reduce static electricity too when it rains
<azonenberg_work> lol
<azonenberg_work> i'm putting in a conductive epoxy floor, static should not be an issue :p
<azonenberg_work> Latest addition to the lab btw: https://i.imgur.com/p6XQloj.jpg
<azonenberg_work> Because i totally need a manual alarm pull box :p
<daveshah> nice
<SolraBizna> have you ever thought to yourself "Golly, I wish I hadn't installed that manual alarm"?
<daveshah> is it interfaced with anything (isolation or suppression?) or just a sounder?
<azonenberg_work> daveshah: so, the existing setup was interconnected smoke detectors
<azonenberg_work> Each unit has 120V mains in, plus a 9V battery bvackup
<azonenberg_work> plus a low voltage DC interconnect line
<azonenberg_work> there is modulated data on the line for CO alarms, or 9V DC to signal smoke
<azonenberg_work> Kidde sells a UL listed relay module that filters for the smoke alert
<azonenberg_work> and wont trip on CO or other alerts
<azonenberg_work> the relay module also spits out 9V DC which is meant to be used for supplemental alarm triggers
<azonenberg_work> so my pull box just closes a circuit from that to the interconnect line, thus triggering the built-in alarms in all of my existing smoke detectors
<daveshah> Very neat
<daveshah> Did your interconnecting smoke alarms come with a warning not to mix polarities between them like the ones I have at home?
<daveshah> Seem they use a capacitive dropper for power
<azonenberg_work> interesting - and no, i just hook hot/neutral/data up based on the color coding
<daveshah> So if line and neutral are swapped on one, the low voltage DC becomes mains
<azonenberg_work> lol
<daveshah> Suspect yours are better than that though
<azonenberg_work> well i do know that the interconnect signal is referenced to neutral
<azonenberg_work> since there's no earth reference
<daveshah> Does sound like the same then
<azonenberg_work> Anyway in addition to that, the relay circuit itself is fed by 24V DC
<azonenberg_work> (it may not be a cap dropper, just a non isolated psu)
<azonenberg_work> So when the alarm triggers i get 24V DC out on another line
<azonenberg_work> This will eventually trigger a horn/strobe unit in the lab, but UPS is being slow and it isnt here yet :p
<azonenberg_work> Way down the road i do plan to add an Inergen gas fire suppression system but that's not going to happen soon (budget)
<daveshah> All sounds like good fun
<azonenberg_work> additionally, i plan to integrate the relay circuit with the UPS EPO so that a pull box activation or heat indication in the lab (and only the lab, using a diode for direction sensing) will kill power to most of the lab
<gruetzkopf> so i grabbed a few broken smoke detectors of the system i use
<azonenberg_work> the theory being that most plausible fires are electrical in nature
<azonenberg_work> Thus the first thing to do if one breaks out is shut it all down
<gruetzkopf> just need a controller now
<gruetzkopf> then i can scope comms
<daveshah> Yes, I guess in most cases shutting things down as soon as any considerable smoke appears might even stop a fire altogether
<daveshah> If it's an overheating type failure
<gruetzkopf> yeah, fire alarm in one of the tech rooms just kills power here
<gruetzkopf> first the big DC contactors, then 3ph supply
<gruetzkopf> (also sets the generator interlock)
<azonenberg_work> daveshah: I do not have smoke detectors in the lab at the moment, i was concerned about nuisance triggers from soldering and such
<azonenberg_work> so i have heat detectors only
<azonenberg_work> i may swap the one near the server rack out for smoke and keep the one closer to the soldering area as heat
<gruetzkopf> i have combined heat/smoke detectors everywhere
<gruetzkopf> heat trigger is programmable
<azonenberg_work> I have CO at the top and bottom of the stairs, the rest of the house is just smoke
<gruetzkopf> some have integrated alarm sounders
<azonenberg_work> (there's no fuel burning appliances at the moment so i dont see CO as being a major need)
<gruetzkopf> generator room has CO here
<azonenberg_work> the smoke are dual sensor ionization + photoelectric
<azonenberg_work> then the lab has heat
<gruetzkopf> no ionisation detectors here yet
<azonenberg_work> Which will reduce nuisance alarms
<azonenberg_work> they're not suitable for life safety applications but nobody is going to be sleeping in the lab
<azonenberg_work> so thats fine
<azonenberg_work> they're non-mandatory supplemental detectors
<azonenberg_work> (garages i dont think even require detectors at all by code)
<daveshah> I would guess that any inergen system would mainly be for property protection, so would warrant better detectors?
<azonenberg_work> It would have a delay built in
<zkms> there's stuff like uhhh
<zkms> aspirating smoke detectors
<azonenberg_work> smoke detected, ring alarm, wait 1 minute or for manual pull station, then deploy agent
<zkms> and also open-air optical smoke detectors
<azonenberg_work> zkms: yeah my concern was that soldering generates smoke
<azonenberg_work> i deliberately did not want to be too sensitive there
<daveshah> could also trigger immediately if two smoke detectors activate
<daveshah> unlikely soldering would set that off
<azonenberg_work> yeah, with a commercial alarm system you could do much more complex stuff
<azonenberg_work> daveshah: it would also be for safety of occupants of the house if something happens in the lab
<azonenberg_work> contain fire to the lab and suppress
<daveshah> Systems like that are quite common with delayed evacuation systems in the UK
<azonenberg_work> (alarm at one, suppress at two? yeah)
<azonenberg_work> i would eventually like to have a water sprinkler system in the house proper
<azonenberg_work> but that may not happen due to budget
<zkms> water sprinklers might get you better insurance rates, idk
<gruetzkopf> pull triggers are rare here
<daveshah> I'm also thinking about the delayed evacuation systems common to minimise disruption in major infrastructure like the tube in the UK
<azonenberg_work> zkms: it would but they're $$$$ to install
<gruetzkopf> usually push-button behind glass
<azonenberg_work> esp in a retrofit
<zkms> awh ;;
<daveshah> The first detect trigger will active an inspector sands announcement over the pa
<daveshah> So someone can investigate
<daveshah> Then various criteria cause an actual evacuation
<azonenberg_work> gruetzkopf: The purpose of the pull station is for me to tip off people upstairs if something goes really bad in the lab
<azonenberg_work> give them an extra 30 sec to evacuate before there's a big enough fire for the alarm to ring
<gruetzkopf> yeah i have push-button alarms everywhere
<gruetzkopf> most are missing their glass cover
<azonenberg_work> yeah no covers on this
<azonenberg_work> its in a secured area, i dont expect vandalism/false alarms to be an issue
<azonenberg_work> the lab will be off limits to any future nerdlings too
<daveshah> In the UK the glass cover is the alarm
<daveshah> No push buttons here
<gruetzkopf> my fire alarm system is basically to code
<gruetzkopf> but not connected to "official" go-direct-to-fire-station network
<azonenberg_work> mine is in excess of residential code but doesnt meet commercial code as its mostly built out of resi components
<azonenberg_work> the lab in general is like that
<azonenberg_work> i'm being tested to commercial code but tried to target commercial standards when possible
<azonenberg_work> being tested to residential*
<gruetzkopf> we're well in excess of commercial minimum
<gruetzkopf> we wouldn't even need a fire alarm system by code, and we have like basically double the detectors / room that code wants, on 2 seperate rings
<azonenberg_work> I have one on each side of the lab, one in every bedroom, one at the top of the stairs and one in the mudroom at the bottom
<azonenberg_work> but it's not a full commercial fire alarm system with a FACP
<azonenberg_work> its just peer to peer interconnected alarms that i am hacking some extra features into
<gruetzkopf> i have FACP and everything
<gruetzkopf> just no certified uplink
<gruetzkopf> dry contact into ISDN/IP/GSM alarm thingy from the burglar alarm, and then horrible stuff to get alarm texts from the backup operator panel via modbus/TCP
<azonenberg_work> well it wouldnt be that hard to upgrade later on
<azonenberg_work> i have 14/4 MC/FPLP running to each alarm station
<gruetzkopf> no hardwired phone/internet yet
<gruetzkopf> so GSM it is
<azonenberg_work> so as long as i can put both sensor and alarm unit in one electrical box (they need not be self triggering) i could put whatever i want there
<gruetzkopf> having sounders in the detectors is quite convenient
<azonenberg_work> Right now my standard is black/white = mains AC, green = safety earth, red = 9V interconnect signal reference to mains neutral, blue = 24V DC triggered by relay during alarm state
<azonenberg_work> for supplemental alert devices
<azonenberg_work> also speaking of modbus and such i was just talking to somebody in anoerht channel
wbraun has quit [Quit: wbraun]
<azonenberg_work> about building a not-sucky PLC based on modern tech free of legacy BS
<azonenberg_work> it would be based on probably a small spartan-7 FPGA, power and upstream communications via gigabit PoE
<gruetzkopf> JB-Y(ST)Y 2*2*0.8 for me, and i only really need one pair
<gruetzkopf> not-sucky PLC IO for me is ethercat stuff