sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
harryho has joined #m-labs
mtrbot-ml has quit [Remote host closed the connection]
mtrbot-ml has joined #m-labs
harryho has quit [Remote host closed the connection]
harryho has joined #m-labs
<mtrbot-ml> [mattermost] <harryho> @astro Hello, sorry for the wait. I have just reset the thermostat. Is it working?
harryho_ has joined #m-labs
harryho_ has quit [Client Quit]
harryho has quit [Quit: Leaving]
harryho has joined #m-labs
<mtrbot-ml> [mattermost] <sb10q> I reset it yesterday already
proteusguy has quit [Ping timeout: 245 seconds]
early has quit [Quit: Leaving]
early has joined #m-labs
proteusguy has joined #m-labs
attie has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
harryho has quit [Remote host closed the connection]
ohsix_ has quit [Ping timeout: 276 seconds]
proteusguy has quit [Remote host closed the connection]
m4ssi has joined #m-labs
proteusguy has joined #m-labs
<ZirconiumX> whitequark: What's your general philosophy regarding the nMigen standard library? Are you going to keep it small, or accept submissions?
<cr1901_modern> nmigen-batteries
<ZirconiumX> cr1901_modern: But then we're going to have a HFT company come along with an incompatible stdlib extension called Core
<cr1901_modern> I've only ever successfully used batteries. For some value of success.
<emily> jane street isn't hft :p
<emily> there's nmigen-soc
<emily> hm, maybe jane street does hft
<emily> I got the impression they were more general though
proteusguy has quit [Ping timeout: 240 seconds]
Dar1us_ has joined #m-labs
Dar1us has quit [Ping timeout: 245 seconds]
Dar1us_ is now known as Dar1us
proteusguy has joined #m-labs
<guan> jane street is a market maker, which in this day and age means mostly hft, though they may have some strategies that are not high frequency
* Dar1us wonders what hft stands for
<Dar1us> high frequency trading?
<mtrbot-ml> [mattermost] <sb10q> yeah
<Dar1us> righto
balrog has quit [Quit: Bye]
balrog has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<mtrbot-ml> [mattermost] <hartytp> @astro are there any things you want to discuss re thermostat?
<mtrbot-ml> [mattermost] <hartytp> e.g. regs, temperature conversion, what kind of interface to expose, etc
<mtrbot-ml> [mattermost] <hartytp> @astro: nitpick but I never like things like set_bi_unipolar(false) as too ambiguous IMHO. set_unipolar(false) much more readable
<mtrbot-ml> [mattermost] <hartytp> fwiw, we don't really need 1 setup per channel. might be easier to just use setup0 for all channels so we only have to configure once
<whitequark> ZirconiumX: the standard library (nmigen.lib) has the scope of primitives that are likely to be useful for any complex FPGA project, and nothing beyond that
<whitequark> it's mostly CDC
rohitksingh has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @astro we do want all buffers enabled (otherwise the current draws can cause issues)
proteusguy has quit [Ping timeout: 250 seconds]
proteusdude has quit [Ping timeout: 245 seconds]
<mtrbot-ml> [mattermost] <hartytp> is that a typo? https://git.m-labs.hk/M-Labs/ionpak-thermostat/src/branch/master/firmware/src/ad7172/regs.rs#L203 (same bit index as previous line)
<mtrbot-ml> [mattermost] <hartytp> I don't understand these bit indices. shouldn't this be bit 0? https://git.m-labs.hk/M-Labs/ionpak-thermostat/src/branch/master/firmware/src/ad7172/regs.rs#L205
<mtrbot-ml> [mattermost] <hartytp> AFAICT, you're using the external ref (chip default) which is correct
proteusguy has joined #m-labs
proteusdude has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> still learning rust, but a little on the fence about all these macros. Kind of makes the code a little hard to follow if you can't directly read it
<mtrbot-ml> [mattermost] <hartytp> we want the ENHFILTEN0 (50Hz/60Hz post filtering bit) set
<mtrbot-ml> [mattermost] <hartytp> so we'd then go for ENHFILT0=110 (16.67 SPS)
<mtrbot-ml> [mattermost] <hartytp> ORDER0=00
m4ssi has quit [Quit: Leaving]
<mtrbot-ml> [mattermost] <hartytp> aah yes, eval software fails to start with a LabView error. Nice
<mtrbot-ml> [mattermost] <hartytp> @astro AFAICT we should set SYNC_EN to 0 by default
<mtrbot-ml> [mattermost] <hartytp> well. it's internally pulled up, so I guess it doesn't really matter
<mtrbot-ml> [mattermost] <hartytp> but, generally better to disable that kind of functionality if not used IME
<mtrbot-ml> [mattermost] <hartytp> why check for conversions being finished over SPI rather than just reading the DOUT/RDY microprocessor input? More SPI traffic is likely to degrade the converter noise floor
<mtrbot-ml> [mattermost] <hartytp> otherwise, that all LGTM
<mtrbot-ml> [mattermost] <hartytp> actually, I don't understand the jitter logic here. If the ADC samples at 10Hz ish, is there really any real jitter to speak of?
<rjo> iirc it samples at a couple MHz
<mtrbot-ml> [mattermost] <hartytp> that's the basic sigma-delta rate, but we want to enable the filters and output at something like 16Hz
<rjo> that's the filtered data rate.
<mtrbot-ml> [mattermost] <hartytp> anyway, AFAICT the current firmware has a 10Hz output data rate
<mtrbot-ml> [mattermost] <hartytp> but a reporint data rate of 100us
<mtrbot-ml> [mattermost] <hartytp> (see eg table 24)
mumptai has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> (@rjo yes, sorry, re-reading my previous post I see that I said "the ADC samples at 10Hz ish" that's not correct, mentally I'd typed "the output data rate is " which is why I was confused about your comment)
<mtrbot-ml> [mattermost] <hartytp> (synchronisation issue between brain and fingers(
<mtrbot-ml> [mattermost] <hartytp> anyway, the way I'd do this https://git.m-labs.hk/M-Labs/ionpak-thermostat/src/branch/master/firmware/src/main.rs#L223 is just send each sample back as it comes
<mtrbot-ml> [mattermost] <hartytp> and I don't understand what this is doing https://git.m-labs.hk/M-Labs/ionpak-thermostat/src/branch/master/firmware/src/main.rs#L234
rohitksingh has quit [Ping timeout: 276 seconds]
<rjo> agree. ADC should do the pacing
<mtrbot-ml> [mattermost] <hartytp> what's the point of "Command::Report(mode)"? (as opposed to "Command::Show(ShowCommand::ReportMode)")
<mtrbot-ml> [mattermost] <hartytp> nit, but I'd argue that "offset" or "set-point" is more conventional than "target" for a PID controller
<mtrbot-ml> [mattermost] <hartytp> also, what is the status of the various PWMs? To get current out of the TEC driver I need to:
<mtrbot-ml> [mattermost] <hartytp> PULL FREQ high
<mtrbot-ml> [mattermost] <hartytp> set CTLI, max IN, maxip, max v
<mtrbot-ml> [mattermost] <hartytp> (happy for the maxs to just be set to max for now)
rohitksingh has joined #m-labs
attie has quit [Ping timeout: 268 seconds]
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JeOCr
<_whitenotifier> [m-labs/nmigen] whitequark 2fca690 - hdl.{ast,dsl}: add Signal.enum; coerce Enum to Value; accept Enum patters.
<_whitenotifier> [nmigen] whitequark closed issue #207: First-class enumerated signals - https://git.io/JeYXj
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JeOC6
<_whitenotifier> [m-labs/nmigen] whitequark d03921e - hdl.{ast,dsl}: add Signal.enum; coerce Enum to Value; accept Enum patterns.
ohsix has joined #m-labs
proteusguy has quit [Ping timeout: 268 seconds]
<_whitenotifier> [nmigen] Failure. The Travis CI build failed - https://travis-ci.org/m-labs/nmigen/builds/585729204?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Failure. The Travis CI build failed - https://travis-ci.org/m-labs/nmigen/builds/585729835?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Failure. The Travis CI build failed - https://travis-ci.org/m-labs/nmigen/builds/585729835?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] whitequark commented on issue #172: AsyncFIFO/AsyncFIFOBuffered do not infer BRAMs on iCE40 - https://git.io/JeOWc
<whitequark> hm
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JeOWl
<_whitenotifier> [m-labs/nmigen] whitequark 4777a7b - hdl.{ast,dsl}: add Signal.enum; coerce Enum to Value; accept Enum patterns.
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/585738257?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.98% (+0.14%) compared to e8f79c5 - https://codecov.io/gh/m-labs/nmigen/commit/4777a7b3a2c4cbf449169b23b6b138de64ec1b3f
<_whitenotifier> [nmigen] Success. 85.71% of diff hit (target 82.83%) - https://codecov.io/gh/m-labs/nmigen/commit/4777a7b3a2c4cbf449169b23b6b138de64ec1b3f
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/585738257?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Failure. 82.82% (-0.01%) compared to e8f79c5 - https://codecov.io/gh/m-labs/nmigen/commit/4777a7b3a2c4cbf449169b23b6b138de64ec1b3f
<_whitenotifier> [nmigen] Failure. 82.75% of diff hit (target 82.83%) - https://codecov.io/gh/m-labs/nmigen/commit/4777a7b3a2c4cbf449169b23b6b138de64ec1b3f
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh has joined #m-labs
<mtrbot-ml> [mattermost] <astro> @harryho yes, thank you
<mtrbot-ml> [mattermost] <astro> oh no
<mtrbot-ml> [mattermost] <astro> @harryho within a minute it acted up again :-(
<_whitenotifier> [smoltcp] cjbe opened issue #307: DHCP lease renewal time not respected - https://git.io/JeOlc
rohitksingh has quit [Ping timeout: 246 seconds]
<mtrbot-ml> [mattermost] <astro> @hartytp thanks for the input! incorporating that now...
<mtrbot-ml> [mattermost] <astro> @hartytp biggest question for me is whether my PWM setup works at all.
<mtrbot-ml> [mattermost] <astro> @hartytp `next_report` is in the future; channel==0: sens0, channel==1: sens1
<mtrbot-ml> [mattermost] <hartytp> Okay thanks. I’ll test the pwm setup if you confirm what I need to measure
<mtrbot-ml> [mattermost] <hartytp> Not sure I follow re next_report
<mtrbot-ml> [mattermost] <astro> let's clarify first: should we set the ADC to sample at the required 10 Hz, or should it sample at another rate and we resample to 10 Hz in the firmware?
<mtrbot-ml> [mattermost] <astro> I didn't want to leave that to ADC for now and wrote that resampling/reporting code
<mtrbot-ml> [mattermost] <astro> @hartytp I think not caring about the shared-setup-for-channels feature actually means less code, and the full `setup_channel()` is only run on boot.
<mtrbot-ml> [mattermost] <astro> @hartytp polling over SPI was easier for a start; for a beyond-prototype stage I'd try to do this with an interrupt.
rohitksingh has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> Ok
<mtrbot-ml> [mattermost] <hartytp> For the measurements I want to make the ADC needs to use the correct output data rate 16.7Hz with 50/60Hz postfilter
<mtrbot-ml> [mattermost] <hartytp> The thing I want to measure is noise and that’s totally dependent on the ADC filter config and hence output data rate
<mtrbot-ml> [mattermost] <astro> should I still retain any 10 Hz sampling code or remove it all for direct reporting?
<mtrbot-ml> [mattermost] <hartytp> I worry a little that hammering the spi bus will lead to increased noise, so it may be something we can’t do even at this stage
<mtrbot-ml> [mattermost] <hartytp> 10Hz sampling code?
<mtrbot-ml> [mattermost] <astro> main.rs currently resamples to 10 Hz
<mtrbot-ml> [mattermost] <hartytp> Hmm I thought you configured the ADC to output samples at 10Hz already?
<mtrbot-ml> [mattermost] <hartytp> So no resampling required
<mtrbot-ml> [mattermost] <hartytp> (Well 10samples/2channels=5hz/channel )
<mtrbot-ml> [mattermost] <hartytp> (Odr reg)
<mtrbot-ml> [mattermost] <hartytp> Nb the filters in the ADC are pretty smart. Not so easy to replicate that performance in sw when downsampling without careful filter design
<mtrbot-ml> [mattermost] <astro> ok
<mtrbot-ml> [mattermost] <astro> I pushed updated setup code in response to your hints
<mtrbot-ml> [mattermost] <hartytp> Thanks will look at tomorrow and try flashing
<mtrbot-ml> [mattermost] <hartytp> Do you get samples out with the new code btw?
<mtrbot-ml> [mattermost] <hartytp> One thing I’m not sure of from the datsheet is what to do with the odr reg when using the postfilter
<mtrbot-ml> [mattermost] <hartytp> Eval software crashes on me so asked at the ADI forum
<mtrbot-ml> [mattermost] <astro> in my experience enabling the buffers resulted in samples of 0xff..
<mtrbot-ml> [mattermost] <hartytp> ?
<mtrbot-ml> [mattermost] <hartytp> That’s not good
<mtrbot-ml> [mattermost] <hartytp> Suggests something is borked
<mtrbot-ml> [mattermost] <hartytp> Will see if I can make sense of it
<mtrbot-ml> [mattermost] <astro> give it a try and disable them if you see these obviously invalid values
<mtrbot-ml> [mattermost] <hartytp> Well having said that if you don’t have a load resistor connected then 0xff is what you should measure
<mtrbot-ml> [mattermost] <hartytp> Roughly
<mtrbot-ml> [mattermost] <hartytp> (Ain plus is pulled to vref ain minus to gnd)
<mtrbot-ml> [mattermost] <hartytp> Worth sticking a 10k dummy load in there as a mock thermostoe
<mtrbot-ml> [mattermost] <hartytp> Thermistor
<mtrbot-ml> [mattermost] <hartytp> Anyway will aim to do that tomorrow
<mtrbot-ml> [mattermost] <hartytp> Thanks!
mumptai has quit [Quit: Verlassend]
proteusguy has joined #m-labs
proteusdude has quit [Ping timeout: 258 seconds]
futarisIRCcloud has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
proteusdude has joined #m-labs
rohitksingh has joined #m-labs
_whitelogger has joined #m-labs