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
plonk has quit [Read error: Connection reset by peer]
plonk has joined #m-labs
airwoodix2 has joined #m-labs
airwoodix has quit [Ping timeout: 250 seconds]
airwoodix2 is now known as airwoodix
futarisIRCcloud has joined #m-labs
Eldra has quit [Ping timeout: 260 seconds]
mumptai_ has joined #m-labs
mumptai has quit [Ping timeout: 260 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Stormwind_mobile has quit [Remote host closed the connection]
Stormwind_mobile has joined #m-labs
[Matt] has quit [Ping timeout: 256 seconds]
[Matt] has joined #m-labs
Dar1us_ has joined #m-labs
Dar1us has quit [Ping timeout: 240 seconds]
Dar1us_ is now known as Dar1us
_whitelogger has joined #m-labs
<ryan-summers[m]> jordens: Is there a special openocd configuration needed for firmware bringup? I'm not seeing any of the stm32h7 openocd config files in the openocd configuration folders
<ryan-summers[m]> * jordens: Is there a special openocd configuration needed for Stabilizer firmware bringup? I'm not seeing any of the stm32h7 openocd config files in the openocd configuration folders
Dar1us has quit [Ping timeout: 260 seconds]
Dar1us has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @rjo any thoughts re the phaser noise eater implementation quote we discussed?
<mtrbot-ml> [mattermost] <hartytp> @rjo what's your pipeline looking like? Assuming Greg's guys get you hardware soon, what timeline are we looking at for RF out of Phaser? Is it likely we'll be able to get something faster than the 12 weeks on the quote?
<rjo> ryan-summers: might require a recent openocd: from stabilizer.cfg: https://github.com/ntfreak/openocd/blob/master/tcl/target/stm32h7x_dual_bank.cfg
<rjo> hartytp: I'd like to do this differently this time. Let's start with you writing down a robust specification of what is required. Take su-servo or the Sayma/SAWG servo description as a background. I'd like to avoid a couple of the iterations where I have to determine what you need.
<mtrbot-ml> [mattermost] <hartytp> ok. We did a bit of that in a previous chat and I had the impression that you had what you needed, but I'm happy to write some more detailed notes up as a starting point
<rjo> hartytp: let's stick with the 12 week timeline for the Phaser implementation for now. There might be something earlier for characterization but it will be incomplete.
<mtrbot-ml> [mattermost] <hartytp> ok
<mtrbot-ml> [mattermost] <sb10q> but behavior is different between the two boards or not?
Eldra has joined #m-labs
zng has quit [Ping timeout: 256 seconds]
zng has joined #m-labs
Eldra has quit [Quit: leaving]
mumptai_ has quit [Quit: Verlassend]
mumptai has joined #m-labs
proteus-guy has quit [Quit: Leaving]
proteus-guy has joined #m-labs
<mtrbot-ml> [mattermost] <astro> @hartytp did you start testing the thermostat v2 firmware? I just want to make sure I'm not missing out on your feedback.
<mtrbot-ml> [mattermost] <hartytp> no not yet
<mtrbot-ml> [mattermost] <hartytp> I wasn't aware that the FW was ready for us to test
<mtrbot-ml> [mattermost] <astro> oh, sorry for not communicating that clearly
<mtrbot-ml> [mattermost] <hartytp> that's fine
<mtrbot-ml> [mattermost] <hartytp> in terms of development process, I think it's probably most efficient for you to setup a test rig where you can test the basic functionality yourself
<mtrbot-ml> [mattermost] <hartytp> I'm not expecting you to verify hw performance or anything like that but IME it's inefficient all round if we test each bit of code as you write it
<mtrbot-ml> [mattermost] <hartytp> feedback loop bandwidth is too low
<mtrbot-ml> [mattermost] <hartytp> is there anything you're blocked on?
<mtrbot-ml> [mattermost] <hartytp> is there any aspect of the code that you don't know how to test using your setup?
<mtrbot-ml> [mattermost] <astro> ok, can do, but remember than I'm no expert in the domain
<mtrbot-ml> [mattermost] <hartytp> absolutely
<mtrbot-ml> [mattermost] <hartytp> that's why I'm here to help!
<mtrbot-ml> [mattermost] <hartytp> IMHO the best way of doing this is to break the required functionality down into small pieces (program the DAC Iset etc)
<mtrbot-ml> [mattermost] <hartytp> for any piece feel free to ask me what's required or anything you don't know (register values)
<mtrbot-ml> [mattermost] <hartytp> and how to verify performance/what to expect
<mtrbot-ml> [mattermost] <hartytp> e.g. for the Iset DAC the DAC output goes to an ADC
<mtrbot-ml> [mattermost] <hartytp> so it's worth getting the ADC up and running (we need it for the TEC offset calibration anyway)
<mtrbot-ml> [mattermost] <hartytp> the TEC driver reference also goes to the ADC so we can start by reading that and checking that it's 1.5V as specified by the data sheet. That would be a good next step AFAICT
<mtrbot-ml> [mattermost] <astro> I'm not yet sure what ADC input to expect from our current lab setup
<mtrbot-ml> [mattermost] <hartytp> ok
<mtrbot-ml> [mattermost] <hartytp> sec while I find the schematics
<mtrbot-ml> [mattermost] <hartytp> do you have them?
<mtrbot-ml> [mattermost] <hartytp> regardless of the setup (i.e. the external connections) the TEC driver produces a 1.5V reference on pin 4
<mtrbot-ml> [mattermost] <hartytp> from the BD on page 10 of the MAX1968 datasheet it looks like the REF is enabled even when the chip is shutdown, but I couldn't be 100% sure about that without measuring
<mtrbot-ml> [mattermost] <astro> yes, I open them in the altium online viewer
<mtrbot-ml> [mattermost] <hartytp> cool (there is also a PDF in the releases page)
<mtrbot-ml> [mattermost] <hartytp> on schematic page 7 (in the pdf) you can see the microprocessor connections
<mtrbot-ml> [mattermost] <hartytp> TEC 0 vref goes to PA0
<mtrbot-ml> [mattermost] <hartytp> TEC1 vref goes to PA3
<mtrbot-ml> [mattermost] <hartytp> The CPU ADC ref looks to be 3V0 driven by an OpAmp (5V0 and then a potential divider)
<mtrbot-ml> [mattermost] <hartytp> (R87 and R88)
<mtrbot-ml> [mattermost] <astro> I am still searching for the link to that PDF...
<mtrbot-ml> [mattermost] <astro> which file?
<mtrbot-ml> [mattermost] <hartytp> So I'd try reading those two ADC channels out (in the long run there are a few other channels you may find useful during debugging, but that would be a good start)
<mtrbot-ml> [mattermost] <hartytp> https://github.com/sinara-hw/thermostat/releases
<mtrbot-ml> [mattermost] <hartytp> Thermostat.Standalone.PDF
<mtrbot-ml> [mattermost] <hartytp>
<mtrbot-ml> [mattermost] <hartytp> (not the most obvious naming I admit)
<mtrbot-ml> [mattermost] <astro> oh, I was looking at my git checkout :)
<mtrbot-ml> [mattermost] <hartytp> yeah, the PDFs are huge so we publish them as releases rather than putting then in VC
<mtrbot-ml> [mattermost] <astro> ok, I'll see what I can do with these pins...
<mtrbot-ml> [mattermost] <astro> thank you
<mtrbot-ml> [mattermost] <hartytp> Cool! Let me know how you get on. Might be worth checking those are within spec (roughly defined by the ref accuracy and the accuracy of the adc ref divider) as part of BST
Getorix_ has joined #m-labs
Getorix has quit [Ping timeout: 240 seconds]
mauz555 has joined #m-labs
mauz555 has quit []
ohsix_ has quit [Read error: Connection reset by peer]
ohsix has joined #m-labs