vagrantc has joined #beagle
Midjak has quit [Quit: This computer has gone to sleep]
m-atoms has quit [Ping timeout: 252 seconds]
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 260 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #beagle
vagrantc has quit [Quit: leaving]
buzzmarshall has quit [Quit: Konversation terminated!]
xet7_ has joined #beagle
akaWolf has joined #beagle
ikarso has joined #beagle
Guest61 has joined #beagle
foxhole_ has quit [Remote host closed the connection]
CrazyEddy has joined #beagle
waldo323 has quit [Remote host closed the connection]
waldo323 has joined #beagle
rob_w has joined #beagle
Guest18 has joined #beagle
<Guest18> BBONE-AI
<Guest18> Please tell if the extended or commercial variant of the AM5729 is used
jfsimon1981 has joined #beagle
Guest18 has quit [Quit: Client closed]
florian has joined #beagle
marcheu has quit [Ping timeout: 248 seconds]
marcheu has joined #beagle
renrelkha has quit [Ping timeout: 240 seconds]
renrelkha has joined #beagle
Midjak has joined #beagle
<Guest61> Hi, it's me again with the beagle booting MLC NAND. I think it works now.  Thanks @zmatt!! I do have to use 2nd option for BCH poly - and (how crazy is that), I forget to double write each sector. So  finally it creates out if 1kbyte code not just 2 (by adding BCH) but 4kbyte by double write that. omg!!! The real bad thing with that TI coding is,
<Guest61> this will recognize that as bad block by all kind of flash tools, which make handling extremely difficult. Once written you can't even erase it without scrub  (delete bad blocks) and this is (in my uboot) affecting the complete flash. So it wipes even the correct bad block markers.
<Guest61> Seems I need at flash_erase that forces to erase even blocks that are marked as bad.
Shadyman has quit [Remote host closed the connection]
<zmatt> Guest61: lol
<Guest61> yeah, what a mess.  but happy to see it booting again!
<Guest61> tests with biterrors are not done yet, don't know whether correction really works
<zmatt> yeah, you should probably first fix the issue of not being to erase these blocks normally
<zmatt> if need be add a custom erase command that just ignores the bad block bits
<zmatt> once you can easily reflash these blocks, you can more easily perform additional tests, e.g. with intentional bit errors
Guest61 has quit [Quit: Client closed]
Guest61 has joined #beagle
jfsimon1981 has quit [Ping timeout: 248 seconds]
lucascastro has joined #beagle
mattb0ne has joined #beagle
<mattb0ne> back
<mattb0ne> damn internet monopolies
<mattb0ne> my service sucks but I have no other options
<mattb0ne> just read all that
ikarso has quit [Quit: Connection closed for inactivity]
<mattb0ne> I thinkk the code works well but I think I need to account for the load cell delay. When I say running a bit slow... the input signal "should" take a second. The code will take about 1.7 seconds to finish a period according to the messages being streamed to the ring buffer
<mattb0ne> I can take the filtering off to boost the sample rate to 1200 samples per second just to test
<zmatt> I don't understand what you mean
<mattb0ne> or I can increment by two to see if that gets to .85 seconds a period.
<mattb0ne> let me share a plot
<zmatt> ????
<zmatt> your signal period will be signal length (number of data points in array) divided by load cell sample rate
<zmatt> if you want your signal to have a 1 second period, then make the signal length equal to the load cell sample rate
<zmatt> uhh, "control" here is the signal input?
<zmatt> or, what's what here?
<mattb0ne> refrence that I am trying to match. Nothing to do witht he coding. Focus is on the Magnapress Input vs Magnapress Output
<zmatt> what do those mean?
<mattb0ne> Magnapress Input is the 1000 points I put into shared memeory assuming a constant dt of .001 seconds
<zmatt> that assumption is wrong, so why would you assume that?
<mattb0ne> Magnapress Actual is the position read from the encoder
<mattb0ne> well the PID loop code on the PRU assumes a constant dt right?
<zmatt> also, where do you even use that assumption?
<zmatt> seriously, can you go back to irclog and read what I said _AGAIN_ ?
<mattb0ne> That assumption is in how the Input curve is plotted. I assume my x axis (time) is 0.000, 0.001 etc...
<zmatt> that assumption is wrong, you know the actual timing of the data PRU sends you
<mattb0ne> for the actual I do
<mattb0ne> and that is what is plotted but when I am generating the input signal my assumption is what I told you
<zmatt> which is wrong
<mattb0ne> I can change that
<mattb0ne> otherwise the code works great
<mattb0ne> I just misinterpreted the dt thing being constant
<zmatt> dt is constant, it's equal to the interval of load cell samples
<zmatt> which is the period of your entire main loop
<mattb0ne> so I can basically ignore all other operations, I do not need to account for any other instructions or is the PRU so fast
<zmatt> which is the period of the PRU messages
<zmatt> which is the period of EVERYTHING in your program.... it's all synchronized together
<mattb0ne> right my call for a load cell value is blocking
<mattb0ne> so it decides the overall speed
<zmatt> exactly, so one load cell sample = one loop iteration = one signal sample used
<zmatt> = one message sent to python
<mattb0ne> so my dt ~ 1.67 ms
<zmatt> the sequence number included in each message is the proper x-axis, measured in load cell samples
<mattb0ne> which matches the graph
<mattb0ne> damn you zmatt
<mattb0ne> so basically to fix I need to shrink my list of 1000 to 600
<zmatt> sequence number modulo signal length is signal index
<zmatt> if you want a 1 second period, then yes
<zmatt> also, why are you back to 600 Hz sample rate? I thought you switched to 1200 ?
<zmatt> maybe I misremember
<mattb0ne> I could but then the data gets super noisy since it is raw. I will try it out
<zmatt> ah
<mattb0ne> i would need better equipment
<mattb0ne> to do better
<zmatt> or filter the data yourself
<mattb0ne> I know even less about filtering than I do about the beaglebone lol
<mattb0ne> :p so I think I will put that on the back burner
<mattb0ne> plus wouldnt it slow everything down. I guess I could do it after the fact
<mattb0ne> since I am not using it as a control value for anything just an output it does not have to be done real time
<mattb0ne> brb
<zmatt> which filter setting are you using?
otisolsen70 has joined #beagle
Guest61 has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
otisolsen70 has quit [Ping timeout: 248 seconds]
jfsimon1981 has joined #beagle
otisolsen70 has joined #beagle
buzzmarshall has joined #beagle
xet7_ has quit [Quit: Leaving]
xet7 has quit [Quit: Leaving]
<mattb0ne> the IIR filter setting 2
xet7 has joined #beagle
<mattb0ne> I got to go do some lab stuff but zmatt don't you go and make a fancy filter on me lol be back later
mattb0ne has quit [Ping timeout: 248 seconds]
otisolsen70 has quit [Quit: Leaving]
<zmatt> mattb0ne: oh I'm not, however I am going to show you how not-fancy the filtering in the EM100 is ;) this is just meant for illustration (and also completely untested, didn't even check it compiles)
<zmatt> for PRU it would need to be rewritten to avoid floats of course
<zmatt> of course, since PRU isn't actually using the load cell measurement, you can just do the filtering in python
<zmatt> also, I'm pretty sure the filter attenuation values at 200 Hz given in the EM100-G user manual are wrong, and I think I know how they messed up: they used the frequency response of the right filter spec (2nd-order butterworth with given cutoff frequency) but the wrong sample rate (600 Hz instead of 1200 Hz)
<zmatt> (resampling to half the sample rate is done by first filtering at the original sample rate and then just discard every other sample)
vagrantc has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 276 seconds]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #beagle
florian has quit [Quit: Ex-Chat]
Amgine[m] has joined #beagle
mattb0ne has joined #beagle
m-atoms has joined #beagle
m-atoms has quit [Ping timeout: 240 seconds]
m-atoms has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Shadyman has joined #beagle
Midjak has quit [Quit: This computer has gone to sleep]
ikarso has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 248 seconds]
Posterdati has quit [Ping timeout: 248 seconds]
mattb0ne has quit [Ping timeout: 240 seconds]
Posterdati has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Guest57 has joined #beagle
<Guest57> hello
Guest57 has quit [Client Quit]
<zmatt> (hi?)
ikarso has quit [Quit: Connection closed for inactivity]
jfsimon1981 has quit [Ping timeout: 256 seconds]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Ping timeout: 246 seconds]
mattb0ne has joined #beagle
<set_> @zmatt: You made it back!
<set_> Where have you been?
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<zmatt> ???
<set_> No triple question marks today, sir.
<set_> Where have you been?
<set_> Sitting while chatting or walking in a pace mode being alleviated?
<set_> Tell me!
<set_> Please.
<zmatt> what do you mean "where have you been?" ... I've been active in here every day since we last spoke, which was a few days ago
<set_> Oh.
<set_> Okay.
<set_> When was the last time you went to Vegas?
<set_> and was it for a BBB conference?
<zmatt> I've never been in vegas, and the last time I was in the US was when I was still a teenager
<set_> Oh.
<set_> Did you travel to this lovely state of Louisiana?
<set_> Or just being safe and going around?
<set_> I am asking b/c some people, you know them, just seem to miss our state and then never come back if they have ever lived here.
<set_> Anyway, no issue.
<zmatt> I mostly remember New York, I think I've also been to Boston but I don't remember much, I may have been too young
<set_> Oh.
<set_> Okay.
<set_> Well, Boston is known for pizza, the Red Socks...and etc.
<set_> Oh! I dislocated my back taking off some red sock. Ha.
<set_> No joke.
<set_> I just healed today and went back to work. Now...
<set_> Did you ever...did you ever reply to me asking about your resource for GPIO?
<zmatt> dunno, check irc log? I'm not sure what question you're talking about
<set_> You made a GPIO library for the BBB with sysfs.
<set_> I think it is called Sysfs-GPIO.
<zmatt> yes, what about it?
<set_> Have you left it in the past or are you still working on it?
<zmatt> what work does it still need?
<set_> And! The kicker. Are you going to add PWM functionality to it?
<set_> Oh.
<set_> None but PWM.
<zmatt> no since it's a gpio library, not a pwm library
<set_> Oh. Okay. I accept it and lie in wait for something to make me understand.
m-atoms has quit [Ping timeout: 248 seconds]
<set_> Your GPIO lib. does not need anything. It covers all bases.
<set_> Up, down, pos, neg, and in, out.
<zmatt> it provides the functionality I wanted it to have, which is pretty much all the functionality of the sysfs gpio interface itself
<set_> More than I would have ever thought I needed. But, there are use cases for rising edge or falling edge.
<set_> Right. I noticed.
<set_> I even looked up die.
<set_> I do not understand it.
<set_> It is like, do it or die.
<set_> Ha.
<set_> And by die, error out.
<zmatt> it prints a message and exits... what's there to not understand?
<set_> Previously, I was reading the man pages on die. I must have read them over and over blindly. B/c I missed exactly how it does it.
<zmatt> it has no man page, it's just a function in my code
<set_> Oh.
<set_> I looked up die in the man pages.
<set_> This is where I took a wrong turn.
<set_> I found it if you wanted to know.
<set_> Let me see if I can find it again.
<zmatt> then whatever you found is unrelated
<set_> Okay.
<set_> Well, I am hitting 0 for 0 now. I probably should quit it for now.
<set_> @zmatt: Again, thank you for being there in chat to calm me down.
<set_> I needed it.
<set_> Although based slightly around the BBB b/c of sysfs and GPIO, my take on it went left and quickly. Sorry.
<zmatt> my library is not BBB-specific
<set_> Oh.
<set_> Hmm. Okay.
<set_> I figured it could work with other related types of boards w/ Linux and sysfs.
<zmatt> it should work on any linux system that has gpio
<set_> I found a lot of source these days. People just give random snippets out. Some work and some do not work. But...they work for a reason and they do not work for a reason.
<set_> Nice!
<set_> This is the excitement of my current state for now.
<set_> and building w/ crosstool-ng.
<zmatt> anyway, I'm off, zZ
<set_> Fine.
<set_> I love me too.
<set_> Typo.
<set_> I should have said, "I really love me too!"
<set_> Ha.
<set_> Later!
mattb0ne has quit [Quit: Leaving]