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
zng has quit [Quit: ZNC 1.7.2 - https://znc.in]
zng has joined #m-labs
<mtrbot-ml> [mattermost] <sb10q> @astro are you using the swi features? Otherwise I can also connect another JTAG probe that is hopefully less buggy
harryho has joined #m-labs
<mtrbot-ml> [mattermost] <harryho> @astro Done!
<Dar1us> you need a debugger for your debugger (dawg)
harryho has quit [Remote host closed the connection]
harryho has joined #m-labs
attie has joined #m-labs
<mtrbot-ml> [mattermost] <sb10q> yeah, typical embedded trash
<mtrbot-ml> [mattermost] <sb10q> sigh
<Dar1us> If I had a dollar for every time arm GDB got confused and asked me if I wanted to debug it I would have.. many dollars
sb0 has quit [Quit: Leaving]
attie has quit [Ping timeout: 258 seconds]
lkcl has joined #m-labs
harryho has quit [Remote host closed the connection]
harryho has joined #m-labs
<_whitenotifier> [nmigen] whitequark opened issue #210: Unify Value.nbits and Value.width - https://git.io/JeO7C
<_whitenotifier> [nmigen] whitequark commented on issue #113: Towards release 0.1 - https://git.io/JeO7W
<_whitenotifier> [nmigen] whitequark closed issue #113: Towards release 0.1 - https://git.io/fjolA
<_whitenotifier> [nmigen] whitequark commented on issue #66: Allow changing encoding for Array - https://git.io/JeO74
mtrbot-ml has quit [Ping timeout: 268 seconds]
harryho has quit [Ping timeout: 245 seconds]
mtrbot-ml has joined #m-labs
harryho has joined #m-labs
harryho_ has joined #m-labs
harryho has quit [Read error: Connection reset by peer]
harryho_ has quit [Quit: Leaving]
harryho has joined #m-labs
mtrbot-ml has quit [Remote host closed the connection]
harryho has quit [Ping timeout: 245 seconds]
mtrbot-ml has joined #m-labs
harryho has joined #m-labs
sb0 has joined #m-labs
rohitksingh has quit [Ping timeout: 265 seconds]
_whitelogger has joined #m-labs
rohitksingh has joined #m-labs
<cr1901_modern> Without knowing much about the thermostat; what prevents it from being reset remotely (w/ authorization)?
<whitequark> it's PoE
<cr1901_modern> Why is that a problem?
<cr1901_modern> (I know jack about PoE)
<whitequark> well, how would you reset PoE?
<cr1901_modern> PoE relay that turns the device off and on again
<whitequark> there are no such devices
<cr1901_modern> (or a remote-controlled relay)
<whitequark> if you had a really fancy PoE switch it could let you control the ports individually. m-labs doesn't have one
<cr1901_modern> https://www.dfrobot.com/product-1218.html I'm trying to look at this, if the site ever loads
<cr1901_modern> okay nevermind
<cr1901_modern> this can be controlled over PoE, it doesn't let you actually reset PoE ports
<cr1901_modern> >if you had a really fancy PoE switch it could let you control the ports individually.
<cr1901_modern> Well, there goes my backup idea of "disable power before or after the PoE port using a USB relay"
<Dar1us> power the switch from a UPS with switchable outlets ;)
<whitequark> you could disable the power to the thermostat but you have to sequence it correctly with disabling power to the debugger
<whitequark> since they both hang
<Dar1us> whitequark: uuugh
<Dar1us> I have an MSP430 device like that
<Dar1us> so tedious if you get the order wrong
<_whitenotifier> [nmigen-boards] whitequark created branch de10_nano - https://git.io/fjuYk
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 2 commits to de10_nano [+2/-0/±0] https://git.io/JeO5g
<_whitenotifier> [m-labs/nmigen-boards] whitequark 3e9ae1f - ADd Numato Mimas (V1).
<_whitenotifier> [m-labs/nmigen-boards] whitequark 12b6e6a - Add DE10-Nano.
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0] https://git.io/JeO5a
<_whitenotifier> [m-labs/nmigen-boards] whitequark 74451ca - Add Numato Mimas (V1).
<cr1901_modern> which one? Admittedly I lost a few hours a few days ago trying to figure out whether mspdebug supports remote detach (it doesn't- there's a config file option to restart the gdb server on kill) because I didn't read the manual.
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to de10_nano [+1/-0/±0] https://git.io/JeO5V
<_whitenotifier> [m-labs/nmigen-boards] whitequark 37da68b - Add DE10-Nano.
<_whitenotifier> [nmigen-boards] whitequark opened pull request #29: Add DE10-Nano - https://git.io/JeO5w
<Dar1us> cr1901_modern: The Ti dongle, mspdebug and Code Composer seem to do it
<cr1901_modern> the PCB shaped like a rocket?
<Dar1us> I didn't get past "this is janky and annoying so I need to put the kid gloves on"
<Dar1us> no, the blck silicone(?) Ti debugger
<Dar1us> custom VHF power amplifier is the debugee
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to de10_nano [+0/-0/±1] https://git.io/JeO5o
<_whitenotifier> [m-labs/nmigen-boards] whitequark e77daf8 - numato_mimas: SW* are actually buttons.
<mtrbot-ml> [mattermost] <sb10q> yeah in hindsight I should have definitely gotten a PoE switch with controllable port, because of course embedded devices always fuck up and need power cycles etc.
<_whitenotifier> [nmigen-boards] whitequark synchronize pull request #29: Add DE10-Nano - https://git.io/JeO5w
<cr1901_modern> Not familiar w/ it... I use a Launchpad for all msp430 debugging/programming
<Dar1us> perhaps a separate PoE injector and a relay to control power to that would be the cheapest/simplest way to make it remotely power cyclable
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to de10_nano [+0/-0/±1] https://git.io/JeO5K
<_whitenotifier> [m-labs/nmigen-boards] whitequark 3392b87 - numato_mimas: add spi_flash#0 resource.
<_whitenotifier> [nmigen-boards] whitequark synchronize pull request #29: Add DE10-Nano - https://git.io/JeO5w
<cr1901_modern> the hell's a PoE injector?
<whitequark> ugh wrong branch
<Dar1us> cr1901_modern: MSP-FET430UIF
<whitequark> cr1901_modern: you could open a wikipedia article on PoE, you know
<Dar1us> cr1901_modern: a PoE injector DC biases the ethernet lines
<Dar1us> like a PoE switch but dumber
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JeO56
<_whitenotifier> [m-labs/nmigen-boards] whitequark a98304e - numato_mimas: SW* are actually buttons.
<_whitenotifier> [m-labs/nmigen-boards] whitequark 1faf631 - numato_mimas: add spi_flash#0 resource.
<cr1901_modern> I didn't want to open a wikipedia article
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to de10_nano [+1/-0/±0] https://git.io/JeO5i
<_whitenotifier> [m-labs/nmigen-boards] whitequark dd712ea - Add DE10-Nano.
<_whitenotifier> [nmigen-boards] whitequark synchronize pull request #29: Add DE10-Nano - https://git.io/JeO5w
<cr1901_modern> Dar1us: Huh, less than $50 on AliExpress, not bad at all
<cr1901_modern> Can an injector be used when the port that leads to the switch already is using the Ethernet lines for power w/o destroying the device?
<cr1901_modern> (since the m-labs switch supports PoE)
<cr1901_modern> w/o destroying the injector*
<Dar1us> cr1901_modern: I assume the inject is capacitively coupled to the switch side but probably worth checking I suppose...
harryho has quit [Ping timeout: 245 seconds]
sb0 has quit [Ping timeout: 265 seconds]
mtrbot-ml has quit [Ping timeout: 276 seconds]
harryho has joined #m-labs
sb0 has joined #m-labs
mtrbot-ml has joined #m-labs
<zignig> if it is a reasonable capable switch , you should be able to switch the poe for a port on and off with a snmp write?
<zignig> what brand is it ?
* zignig had to reboot a POE device from time to time a few years ago.
cedric has quit [Ping timeout: 240 seconds]
<mtrbot-ml> [mattermost] <sb10q> zignig: Netgear GS308P
<mtrbot-ml> [mattermost] <sb10q> I don't think it has SNMP, does it?
cedric has joined #m-labs
cedric has joined #m-labs
cedric has quit [Changing host]
<Dar1us> doesn't look like it
attie has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
mauz555 has joined #m-labs
_whitelogger has joined #m-labs
harryho has quit [Remote host closed the connection]
<gruetzkopf> usually poe injectors have transformers in them, they don't backfeed the input port
<mtrbot-ml> [mattermost] <sb10q> @astro I have connected a JTAG cable to thermostat, let's see if the bug is still present
<mtrbot-ml> [mattermost] <sb10q> you need to set the cable detect command to
<mtrbot-ml> [mattermost] <sb10q> source [find interface/ftdi/olimex-arm-usb-tiny-h.cfg]
<mtrbot-ml> [mattermost] <sb10q> it seems to work, but it prints this message
<mtrbot-ml> [mattermost] <sb10q> Warn : JTAG tap: tm4c1294kcpd.cpu UNEXPECTED: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
<mtrbot-ml> [mattermost] <sb10q>
<mtrbot-ml> [mattermost] <sb10q> not sure if that's a real issue or not
<mtrbot-ml> [mattermost] <sb10q> was it printing it already with the ST-Link?
mauz555 has quit [Read error: Connection reset by peer]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 264 seconds]
mauz555 has joined #m-labs
mauz555 has quit [Read error: Connection reset by peer]
<mtrbot-ml> [mattermost] <pathfinder49> pathfinder49 joined the team.
sb0 has quit [Quit: Leaving]
<mtrbot-ml> [mattermost] <pathfinder49> Hi, I'm working with @hartytp on thermostat. Thanks to the new build guide I got the board flashed. However, I'm unsure whether two behaviors I'm seeing are expected. Firstly, the initial read of the ADC is corrupted. Further reads return the correct ID (see here https://pastebin.com/kJ0vQ3Ka). Secondly, the MAC address is read as invalid (see here https://pastebin.com/THDZjj4A).
plonk has quit [Ping timeout: 246 seconds]
plonk has joined #m-labs
plonk has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 276 seconds]
<mtrbot-ml> [mattermost] <pathfinder49> @astro can you have a look at the current command parser implementation plz?
<mtrbot-ml> [mattermost] <pathfinder49> e.g. it's a little confusing that "report\n" gives "Command error: Parser (Tag)\n" (not a helpful error msg)
<mtrbot-ml> [mattermost] <pathfinder49> so one has to send "report \n"
<mtrbot-ml> [mattermost] <pathfinder49> (required trailing whitespace)
<mtrbot-ml> [mattermost] <pathfinder49> also, does the current match for "report mode" work? Looks like it checks for white space twice
mumptai has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 252 seconds]
<mtrbot-ml> [mattermost] <pathfinder49> @sb10q can you remove the large diode by the ADC on your board plz?
<mtrbot-ml> [mattermost] <pathfinder49> @astro https://github.com/sinara-hw/Thermostat/issues/48
<mtrbot-ml> [mattermost] <pathfinder49> can you check the reg map plz?
<mtrbot-ml> [mattermost] <pathfinder49> @astro what is the tick duration? (units of time?)
<mtrbot-ml> [mattermost] <astro> @pathfinder49 tick as in systick? 10 Hz. but `board::systick::get_time()` evaluates the systick registers to produce sub-ms precision
<mtrbot-ml> [mattermost] <astro> @pathfinder49 sorry for the command parser bugs, I was not able to test during the last few days but I will hopefully be able to do so today.
<mtrbot-ml> [mattermost] <astro> @pathfinder49 firmware startup reads the ADC ID in a loop til it's correct *because* of the first read that is always corrupted. I should probably silence the output. (semihosting output must be removed prior to production anyway)
lkcl has joined #m-labs
<mtrbot-ml> [mattermost] <astro> @hartytp which register bits for buffers setup were not correct? or was that fixed by https://git.m-labs.hk/M-Labs/ionpak-thermostat/commit/4587406d44c589c4cdeccd40512f0c285f42f38b ?
rohitksingh has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @astro no your register definition is wrong
<mtrbot-ml> [mattermost] <hartytp> Wrong bot orders
<mtrbot-ml> [mattermost] <hartytp> Bit for buffers etc
<mtrbot-ml> [mattermost] <hartytp> What’s the units of the time for the reporting?
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @astro see data sheet for bits of setup reg the top word but offsets are not right
<mtrbot-ml> [mattermost] <astro> units are nanoseconds
<mtrbot-ml> [mattermost] <hartytp> Ack thanks that’s what I guessed (but can you document at some point)
<mtrbot-ml> [mattermost] <hartytp> Can you expose the post filter sample rate on the eth interface plz? Allows users to trade off noise rejection for loop be
<mtrbot-ml> [mattermost] <hartytp> Bw
<mtrbot-ml> [mattermost] <hartytp> @astro nb your ADC is prob operating out of spec so may play up due to wrong diode on supply (@sb10q can you fix)
<mtrbot-ml> [mattermost] <hartytp> @pathfinder49 can you see if the ADC error still happens now we fixed the rail voltage?
<mtrbot-ml> [mattermost] <astro> @hartytp I just pushed a fix for the wrong SetupCon bits
<mtrbot-ml> [mattermost] <astro> please wish for any configuration bits you would like to control :)
<mtrbot-ml> [mattermost] <hartytp> Still not right I think
<mtrbot-ml> [mattermost] <hartytp> Well I’m also happy to add once the fw is finished, it’s not a big deal
<mtrbot-ml> [mattermost] <hartytp> Nope sorry
<mtrbot-ml> [mattermost] <hartytp> You’re right this time, I most remembered
<mtrbot-ml> [mattermost] <hartytp> Misremembered
<mtrbot-ml> [mattermost] <astro> good
<mtrbot-ml> [mattermost] <astro> thank you for verifying
<mtrbot-ml> [mattermost] <hartytp> Np nice to see working. Want to take a few more Adc measurements then will look at pwm
<mtrbot-ml> [mattermost] <hartytp> These adcs are basically magic though
<mtrbot-ml> [mattermost] <astro> how so?
<mtrbot-ml> [mattermost] <hartytp> 10nK rms noise in such a cheap package. That’s pretty cool.
<mtrbot-ml> [mattermost] <hartytp> Shows how much you can do with a good front end and a lot of dsp
<mtrbot-ml> [mattermost] <hartytp> Also unlike lots of ics I’ve used they are easy to configure, default to sensible values and kind of “just work”
<mtrbot-ml> [mattermost] <hartytp> I’m pleasantly surprised we can stick that ADC so close to a dirty Poe smps, microprocessor etc and still hit sub uV noise floor
<mtrbot-ml> [mattermost] <astro> yeah, that chip is a vanilla SPI peripheral indeed :)
<mtrbot-ml> [mattermost] <hartytp> Yep let’s see what cranking the tec driver to 11 does to the ADC readings
mumptai has quit [Remote host closed the connection]
<mtrbot-ml> [mattermost] <hartytp> Also the 18bit dac on the new version is cool too
<mtrbot-ml> [mattermost] <astro> how do I handle that there are two inputs? do we want separate PID instances that control different PWM channels?
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> You need two different integrators, sets of gains etc
<mtrbot-ml> [mattermost] <hartytp> @astro any idea why our board doesn’t pick up a MAC address from the eeprom? Does this work for you?
gnufan_home has joined #m-labs
<mtrbot-ml> [mattermost] <astro> I haven't touched any of the ethernet setup code from ionpak
<mtrbot-ml> [mattermost] <astro> @hartytp any differences in the hardware?
rohitksingh has quit [Ping timeout: 246 seconds]
<mtrbot-ml> [mattermost] <astro> oh, `ff-ff-ff-ff-ff-ff` here as well
<mtrbot-ml> [mattermost] <hartytp> Okay good to know. Not a prob for now I guess
<mtrbot-ml> [mattermost] <hartytp> Would have to check schematic connections I guess
<mtrbot-ml> [mattermost] <astro> it should be wired to pins that are valid for `tm4c129x::FLASH_CTRL`
<mtrbot-ml> [mattermost] <astro> I'm still getting `sens0=FFFFFF` and `sens1=FFFFFF` with the fixed buffer bits
<mtrbot-ml> [mattermost] <hartytp> Okay well let’s forget about the eeprom for now but make sure it’s connected properly in the next hw rev
<mtrbot-ml> [mattermost] <hartytp> Re the ADC. I think you have two issues: (a) the ADC is running off the wrong rail because of the zener
<mtrbot-ml> [mattermost] <hartytp> (B) you need to add a load resistor
<mtrbot-ml> [mattermost] <hartytp> If you don’t have a resistor then the inputs are tied to vref and gnd so you expect to read fs
<mtrbot-ml> [mattermost] <hartytp> @sb10q can you stick 10ks in the shutter cons plz?
cedric has quit [Ping timeout: 265 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
<mtrbot-ml> [mattermost] <hartytp> @astro oh and let’s remove the odr write since it doesn’t do anything with the postfilter
<mtrbot-ml> [mattermost] <astro> ok