**** BEGIN LOGGING AT Mon Jan 27 02:59:58 2020 Jan 27 03:46:06 WHelp. I corrupted my system somehow. I hope you are happy! Jan 27 03:46:08 Just kidding. Jan 27 04:26:04 well being corrupt isn't such a great thing now is it? anyhow :D Jan 27 04:26:30 Nope! Jan 27 04:26:54 Ha. I got it working again but back to the same issue. The Motor Bridge Cape is only allowing for one second moves so far. Jan 27 04:27:15 I would have to keep pushing the button for forward use. Jan 27 04:28:09 Boy, virtual env's are a terrible thing of the future (so far). Last year, they were great. Something must have changed. Jan 27 04:34:20 This is what I cannot explain: One motor was fine w/ the Motor Bridge Cape and this "new" i2c library. Now, I have four motors but they only work for one or two seconds after commanded. Jan 27 04:37:45 Mystery! Jan 27 04:41:09 can you query the status of the cape? IE find out what it thinks it's state is? Jan 27 04:41:52 Um. Maybe but I do not know how. I just unplugged that one and plugged in a BBBW instead w/ MotorCape. Jan 27 04:42:54 GenTooMan: How would I query the state of the Cape? Jan 27 04:43:10 set_ you have docs on sending commands to the cape? Jan 27 04:43:20 Hmm. No. Jan 27 04:43:28 I do not think they published them. Jan 27 04:43:42 I have some firmware and source, a library, and some other info. Jan 27 04:44:03 check if the library has any functions to get status information Jan 27 04:45:22 The MotorBridge.py file is simple except for the odd listings of ideas outside of python source. I think the code in that file has to do w/ altering the state of the onboard chip (ATmel) and have it work w/ the arm am335x. Jan 27 04:45:30 I am just not sure what that source means. Jan 27 04:46:21 https://github.com/Seeed-Studio/MotorBridgeCapeFirmwareSourceCode/tree/master/Motor Jan 27 04:46:32 That has the files for the motors. Jan 27 04:46:38 I need to review them more, I guess. Jan 27 04:48:29 I think I also never updated the firmware for this Motor Bridge Cape. I will try that too. Hmm. Jan 27 04:50:09 looks to use the I2C bus and it's ST not atmel :D Jan 27 04:51:58 I don't know if they tossed in version information either.. seeed studios makes interesting stuff but sometimes lacks documentation Jan 27 04:52:15 Oh. Dang. You are right. Jan 27 04:52:18 ST...sheesh. Jan 27 04:52:58 Yep. I like this Cape but it has been a thorn in my side for life so far. I am going to flash new firmware for the ST and see if that does anything. Jan 27 04:56:01 Just more issues. Jan 27 04:58:21 "no module named serial" >>> it is trying to import a python package called serial and the machine cannot find it. Jan 27 04:58:23 Hmm. Jan 27 05:08:28 This got complicated and quickly. Off to breaking. Jan 27 05:11:44 good night Jan 27 05:11:54 Okay. Jan 27 05:11:56 pyserial? Jan 27 05:12:01 I tried it. Jan 27 05:12:08 I used pip and apt. Jan 27 05:12:33 oh. Dear. Jan 27 05:12:43 What? Jan 27 05:13:01 pyserial *is* python-serial Jan 27 05:13:13 I certainly know of no other Jan 27 05:13:21 I tried python3-serial. Jan 27 05:13:27 I will try python-serial, too. Jan 27 05:13:30 for python3? or pyton2 .. :p Jan 27 05:13:45 python -v Jan 27 05:13:48 I think this script was back when python2 was around. Jan 27 05:13:56 I have pythong3.5. Jan 27 05:14:08 I wonder if its aliased Jan 27 05:14:26 yea don't mix py2 and py3 .. scripts OR interpreters.. Jan 27 05:14:33 Okay. Jan 27 05:14:47 you'll end up with errors galore Jan 27 05:14:54 I know! Jan 27 05:14:55 Ha. Jan 27 05:15:09 I have some serious errors so far. Jan 27 05:18:44 For now, the issue is that my GPIOs are not available. Supposedly. Jan 27 05:41:19 I set up the GPIOs w/ echo. They disappear. Oh well. Magic! Jan 27 05:46:05 I do not know if you got bored but here: TypeError: startswith first arg must be bytes or a tuple of bytes, not str. Jan 27 05:46:52 It seems it is reading info. from the .bin file and wanting the TypeError to fix itself. Jan 27 05:47:10 Blah. Lost cause for tonight. I will try another day. Jan 27 12:11:46 Should my i2c address show 0 or 1 when I use config-pin -q p9.19? Jan 27 12:38:06 set_: ??? Jan 27 12:39:59 under no circumstance would you see an i2c address in the output of config-pin, nor are 0 and 1 valid i2c addresses in the first place. Jan 27 12:40:53 if you mean i2c bus number, P9.19's i2c mode is for i2c-2 scl. I don't know if that's shown in the output of config-pin, I don't think so Jan 27 12:41:14 if you mean neither of these things, then I don't know what you do mean Jan 27 12:43:52 (the pinmux mode for i2c on P9.19 is mode 3, but that's something I know is definitely not shown by config-pin, since it doesn't deal directly with pinmux modes, it selects named pinmux states declared in DT) Jan 27 12:46:40 Okay. Jan 27 12:47:03 I typed config-pin -q p9.19 and it printed 0. Jan 27 12:47:55 sounds like something broke Jan 27 12:48:26 could be... Jan 27 12:48:59 try: config-pin -q p9.19 || echo "exit code $?" Jan 27 12:49:44 okay. Jan 27 12:50:32 Exit code 0 Jan 27 12:51:26 there is no circumstance under which this snippet would print "exit code 0" (let alone "Exit code 0") so please copy-paste the command and copy-paste the output without trying to paraphrase anything Jan 27 12:51:42 Okay. Jan 27 12:52:18 I tried to copy it and it kicked me out. Jan 27 12:52:19 though I guess more interesting would be: Jan 27 12:52:33 dash -x $(which config-pin) -q p9.19 Jan 27 12:52:39 but it'll be spammy Jan 27 12:52:51 share full output via pastebin Jan 27 12:53:09 "I tried to copy it and it kicked me out" ?? Jan 27 12:53:48 I know. I just tried to copy the input and output and the ssh session went away. Jan 27 12:54:00 I had to sign in again. Jan 27 12:54:27 you probably pressed something weird... regardless, that's between you and your ssh client :P Jan 27 12:54:58 regardless, bbl Jan 27 12:55:02 Wait. Jan 27 12:55:06 I have your paste Jan 27 12:55:17 just paste the link, I'll look when I'm back Jan 27 12:55:36 https://pastebin.com/ErYADS0M Okay! Jan 27 13:47:13 so it didn't print 0, it printed "P9_19 Mode: i2c" Jan 27 13:47:40 so why did you say it printed 0 ? Jan 27 13:48:26 (the lines without + prefix are its normal output, which is just line 547) Jan 27 15:53:50 m Jan 27 18:08:20 @zmatt: That is what printed out to the terminal. config-pin -q p9.19 || echo "exit code $?" is what printed this: exit code 0 Jan 27 18:19:40 documentation for the motor bridge is in "Motor Bridge Cape v1.0 guid ENG.docx" set it does not give much detail, the servo values have status. DCM control does not. Jan 27 18:33:38 set_ the DC motor stuff just sets mode and speed (PWM) and that is that. However DMC_Run can change the mode and speed, function TB_SetWorkMode is a bit suspicious and if you send something out of range to the unit it will likely just stop working. Jan 27 18:37:10 Okay. Jan 27 18:37:17 zmatt: did you say it was possible to configure 4.14 kernels to load uio drivers for shared memory access to the PRUSS data memories and shared data memories while still keeping remoteproc loaded as well? Jan 27 18:37:18 I will go and read it again. Jan 27 18:42:10 GenTooMan: Maybe that is what is happening. Jan 27 18:45:03 TB_SetWorkMode is needs me to set a short break first. Jan 27 18:45:42 Whelp. I can test but not right now. Sorry to cut it short but duty calls. BBL. Jan 27 18:47:11 It is probably the frequency that needs changing. Up, up, and Otay! Jan 27 19:43:51 jkridner[m]: what's going on with the lists? Jan 27 19:44:18 uh-oh.... what is going on with the lists? Jan 27 19:45:20 jkridner[m]: no bounce, but the mail never shows up Jan 27 19:45:32 is it locked downing awaiting moderator? Jan 27 19:45:36 (this is the -alpha) Jan 27 19:46:15 2 post, 2nd one was tried slightly differently but none of it got through Jan 27 19:46:24 looks like you used a new address. Jan 27 19:46:29 it was in the moderation queue. Jan 27 19:46:40 shouldn't block you again. Jan 27 19:46:41 no, i checked my from address, it is the same one I get postings on Jan 27 19:46:50 made sure of it Jan 27 19:47:08 hmmm.... well, it was moderated.... maybe you never posted to that list from that e-mail? Jan 27 19:47:10 seems like google did something in the last month or two Jan 27 19:47:13 anyway, shouldn't happen again. Jan 27 19:47:18 yes I have, one post was a reply to a previous post! Jan 27 19:47:19 :D Jan 27 19:47:28 so I was moderated as a new user, not as spam? Jan 27 19:47:35 yes Jan 27 19:47:45 how odd Jan 27 19:48:22 thanks for fixing it Jan 27 21:34:13 GenTooMan: I have the "datasheet" open for the commands for the Motor Bridge Cape. I am about to plug it in to test. Heads up! Jan 27 21:43:53 So, I see default of DC Motors are 0 (short break), the PWM duty is 0% - 100%, and 1k to 10k is the frequency. Jan 27 21:44:33 What I am asking is if I should takle the pull up/down resistors onboard the BBBGW or the Motor Bridge Cape. Jan 27 21:44:34 ... Jan 27 21:45:19 I am asking b/c i think i have to notify the processor, the am335x, of such a set up beforehand. Jan 27 21:45:23 Does that make sense? Jan 27 21:47:27 Now, PwmDuty should be 0 to 1000 or 0% to 100% as what? "As what," means this: Should I put in the source as up to 1000 or up to 100? Jan 27 21:47:30 What do you think? Jan 27 21:50:41 It is probably, it is, more complicated than I am describing. I know this, man. But... Jan 27 21:51:21 I tested the 1000 already. Oops. Anyway, it performs the same for DC Motors. Start, stop, stop for good even while the source is running. Jan 27 21:56:55 Hello. Sorry. How can I find the address of the /dev/i2c-2 peripheral? Jan 27 22:11:47 so, from what I can understand, the i2c pins need to have a pull up resistor on each of them. Can I perform this by the BBGW or should I look to the Cape? Jan 27 22:13:38 you -can- but I think external ones are recommended Jan 27 22:17:13 Okay. I just tried internally. The BBGW might not have that command in the new kernel w/ config-pin p9.19 i2c+. Jan 27 22:17:34 I just found that the Cape has some on it. So, I can use them. Jan 27 22:17:42 I think the answer lies here: 11. Jan 27 22:17:44 Ha. Jan 27 22:19:11 •IO pull up/down mode：0-pull up，1-pull up，2 - none •IO output mode：0- push pull，1-open drain •IO status ：0-low，1-high Jan 27 22:19:28 So, actually think it must be: 011. Jan 27 22:19:59 I need open drain, right? Jan 27 22:21:31 Or since it is on the outside of the BBGW, I do not need it? Hmm. Jan 27 22:22:05 B/c it is part of the Motor Bridge Cape. Hence, I can use open drain. Blah. I need to read more. Jan 27 23:12:19 Even w/ Adafruit_GPIO.I2C, it only runs for a second or two. Jan 27 23:12:24 Hmm. Jan 27 23:12:53 Battery Test time. Jan 27 23:19:58 Would it not be funny if the served html page was the issue? Jan 27 23:19:59 Oops. Jan 27 23:31:04 Still...just seconds while the script runs. Blah. Jan 27 23:39:48 Well, that is not either. Jan 27 23:41:51 are you setting the right mode? Did you read the document I referenced? I started to peruse the code. Jan 27 23:42:29 jkridner[m]: yes Jan 27 23:43:09 https://github.com/beagleboard/bb.org-overlays/blob/master/examples/noeeprom-capes.txt! Jan 27 23:43:26 I got the source to work and I forgot this info. needs to be adapted. Jan 27 23:43:55 GenTooMan: Yes, I just remembered specific details to this Cape that I had forgotten. Jan 27 23:44:40 jkridner[m]: the uio_pruss_shmem driver is redundant, the mainline uio_pdrv_genirq provides a superset of the same functionality Jan 27 23:45:51 Nope. That was not it. Jan 27 23:46:00 jkridner[m]: in both cases the correct place for the node is inside &pruss_soc_bus rather than &ocp btw (for power management reasons) Jan 27 23:46:27 node or nodes Jan 27 23:47:02 (you can either use one device with multiple memory areas or multiple devices with one memory area each) Jan 27 23:49:20 19:08 < set_> @zmatt: That is what printed out to the terminal. config-pin -q p9.19 || echo "exit code $?" is what printed this: exit code 0 Jan 27 23:49:33 set_: no, it didn't Jan 27 23:49:55 set_: you probably just made a typo or something Jan 27 23:50:18 (despite me saying to copy-paste the command) Jan 27 23:51:27 oh. Jan 27 23:51:38 Okay. Did you read that info. I posted on the paste? Jan 27 23:51:53 Do you want me to try again? Jan 27 23:52:14 yes, and like I said then: 14:47 <@zmatt> so it didn't print 0, it printed "P9_19 Mode: i2c" Jan 27 23:52:53 your paste showed the command working perfectly fine and printing what I'd expect it to print Jan 27 23:53:10 (along with the +-prefixed debug output, which you can ignore) Jan 27 23:53:23 P9_19 Mode: default Direction: in Value: 0 Jan 27 23:53:39 why did you change P9_19 mode ? Jan 27 23:53:47 I just rebooted. Jan 27 23:54:15 oh right, "default" for P9.19 is i2c Jan 27 23:54:43 So, I should make it uart now? Jan 27 23:54:51 ???? Jan 27 23:54:54 Sorry. Jan 27 23:55:07 Is 0 a good value for i2c addresses? Jan 27 23:55:21 I've tried to understand what you've been saying for the last few pages but I honestly can't even begin to guess wtf you're trying to do Jan 27 23:55:41 that question makes no sense Jan 27 23:55:49 what are you talking about? Jan 27 23:55:54 what are you trying to do? Jan 27 23:56:01 @zmatt: I am attempting to make this dang bot work. I have source, a libary, and i guess I need to update the firmware. Jan 27 23:56:09 of what? Jan 27 23:56:26 I never updated the firmware of this ST chip onboard the Motor Bridge Cape. Jan 27 23:56:38 It would not work. Jan 27 23:57:13 But, like the last hyperlink mentions, I need to adjust some pins to make it work. Jan 27 23:57:20 I will try right now. Jan 27 23:57:42 as far as I can tell there's only 1 firmware version for the MotorBridgeCape Jan 27 23:57:47 so there's nothing to update Jan 27 23:58:06 Oh, really. I wonder why they put that update firmware section on their page. Let me show you. Jan 27 23:58:41 https://github.com/Seeed-Studio/MotorBridgeCapeFirmwareSourceCode Jan 27 23:58:48 It is on their wiki too. Jan 27 23:59:08 that's the source code of the firmware, not important Jan 27 23:59:13 Okay. Jan 27 23:59:34 https://github.com/Seeed-Studio/MotorBridgeCapeFirmware is the official firmware repository Jan 27 23:59:49 Oh. Jan 27 23:59:50 Okay. Jan 27 23:59:57 and https://github.com/Seeed-Studio/MotorBridgeCapeFirmware/commits/master is the revision history of that repository... note that after adding the initial version of the firmware, the only changes since then have been to the README Jan 28 00:00:06 they've never added a new firmware release Jan 28 00:00:18 i.e. the first firmware release was also the last Jan 28 00:00:29 Ha. Okay. Jan 28 00:00:45 knowing you, whatever problem you're having is probably your fault :P Jan 28 00:00:51 No way! Jan 28 00:00:56 I had this working. Jan 28 00:01:03 But. probably. Jan 28 00:01:04 so why did you then break it? Jan 28 00:01:07 :) Jan 28 00:01:27 I broke it b/c I needed to use the smbus2 library instead for no reason. Jan 28 00:01:36 instead of what? Jan 28 00:01:47 I saw that the Adafruit_GPIO.I2C library was deprecated. Jan 28 00:01:58 or read only. Jan 28 00:02:09 But...both libraries work the same right now Jan 28 00:02:15 okay, I remember telling you how to replace it by smbus2 yeah Jan 28 00:02:20 Yep. Jan 28 00:02:43 I did and it has not worked since then. At least, I thought it worked b/c one motor would listen to my commands. Jan 28 00:03:08 Now, I have four and things are only working for one second (exactly) and then it, the bot, quits listening. Jan 28 00:03:35 pastebin your modified MotorBridge module please Jan 28 00:03:51 the smbus2 or Adafruit_GPIO.I2C? Jan 28 00:04:02 I have been testing both w/ the same output. Jan 28 00:04:54 I don't understand the question... the original version used Adafruit_GPIO.I2C, you said you modified it to use smbus2, and I just asked for your modified version... what exactly is still unclear? Jan 28 00:05:08 Okay. Jan 28 00:05:20 Please hold. Nothing, I understand the clarification now. Jan 28 00:12:48 https://pastebin.com/jb7D8jkU is it. If you need more, let me know. Jan 28 00:12:55 I have not changed anything else. Jan 28 00:14:44 that change looks fine to me Jan 28 00:14:50 Right. Jan 28 00:15:06 I know. I get part of it. It did work and now it does not. Jan 28 00:15:24 Do you know why it might work w/ one motor and not four? See, that does not make sense. Jan 28 00:15:29 It should work. Jan 28 00:15:29 in other words you changed something else (either in this or in your test code) and that broke stuff Jan 28 00:15:39 Okay. Jan 28 00:15:47 if _any_ motor works, the MotorBridge module is working Jan 28 00:15:52 it's probably your own code Jan 28 00:16:13 The source used to work and now it only works for one second and then quits. Jan 28 00:16:25 pastebin Jan 28 00:16:28 I cannot explain it. That is all I am saying. Jan 28 00:16:41 pastebin? Oh. the source that used to work? Jan 28 00:16:47 Please hold. Jan 28 00:17:01 the source code that isn't working, that's what your question is about after all Jan 28 00:18:25 I am assuming so. I have not other ideas on why this source is not working but did work at one point. Jan 28 00:18:28 Probably me, okay. Jan 28 00:18:50 because you had code that worked and then modified it in a way that turned it into non-working code :P Jan 28 00:19:37 and then proceeded to blame a module that's working fine and started to mess with settings that have no reason to be messed with Jan 28 00:20:00 https://pastebin.com/x7xpFWw5 is something...okay. Okay. Stop. I only know so much. Everyone knows this by now. Jan 28 00:20:22 If it would work, oh. I may have changed something. You are right. Jan 28 00:20:54 I changed the lines below the function. Jan 28 00:21:23 motor.DCMotorInit should be called only once, during initialization, which is why it's called "Init" Jan 28 00:21:36 remove that from your state update function Jan 28 00:21:42 Okay. Jan 28 00:21:52 remove time.sleep from your Flask code (I've said this _COUNTLESS_ times already) Jan 28 00:22:21 I like it but okay. Jan 28 00:22:39 remove the blank line between a decorator (@app.route(...)) and the function is it decorating (def updates(...):), I've also said that countless times Jan 28 00:22:53 I see COUNTLESS as in you are yelling that word. Jan 28 00:22:56 Okay. Jan 28 00:22:59 Sheesh. Jan 28 00:23:28 Okay, so the Inits need to go before the function. That was the issue? Jan 28 00:23:35 time.sleep makes no sense in a web application, all you're doing is make your webserver hang for half a second after you send it a request Jan 28 00:23:48 Okay. Got it. Jan 28 00:23:54 I really understood this time. Sorry. Jan 28 00:24:15 just remove the "import time" altogether Jan 28 00:24:31 done Jan 28 00:24:48 and no I don't see an obvious reason why this code would affect only 1 of 4 motors... have you confirmed that _this_ code exhibits that issue? Jan 28 00:25:00 as in, tested this exact code Jan 28 00:25:02 Yes. Jan 28 00:25:08 I figured I did. Jan 28 00:25:15 test it again, just in case Jan 28 00:25:19 Okay. Jan 28 00:25:23 Where should I put the inits? Jan 28 00:25:27 Before the function? Jan 28 00:26:58 Maybe I had a lapse in judgement. Jan 28 00:27:28 something like this I guess, https://pastebin.com/RZa38nG9 Jan 28 00:27:41 Or a sense of "I done forgotteded" hit me. I cannot believe it is me, again. Jan 28 00:27:49 really? I can Jan 28 00:28:48 Ha. That one motor happened and I got excited. I thought, "I will attach four now and get it to work w/ four of them." Jan 28 00:29:04 I changed the source. I feel like I hav dementia now. Jan 28 00:32:26 I am about to test it. Jan 28 00:32:41 Please wait for your idea to work perfectly and mine, that has failed, to work again! Jan 28 00:34:20 * GenTooMan waits for the confirmation of dementia. Jan 28 00:34:31 I mean something happened or did not. Jan 28 00:35:38 I would cuss but I am excited it works again. Jan 28 00:35:46 Dang it. Jan 28 00:35:49 Thank you. Jan 28 00:36:09 shocking, who'd have imagined Jan 28 00:36:24 I lost exactly 40,000 hairs during this excitement experience. Jan 28 00:36:57 "The dang calls of init go before the functions!" Jan 28 00:37:13 head caught by the motor? Jan 28 00:37:17 On some servers, this is 100% correct! Jan 28 00:37:18 that is not what fixed the problem Jan 28 00:37:30 the problem was that your problem was with different code than what you showed me Jan 28 00:37:36 most likely Jan 28 00:37:40 Oh. Jan 28 00:37:54 moving the intialization is just because it makes no sense to keep reinitializing the motors Jan 28 00:38:01 and it would cause problems sooner or later Jan 28 00:38:07 I changed the source to make the init commands go before the function. Jan 28 00:38:11 (e.g. cause them to spaz out) Jan 28 00:38:17 Now, it works out. Jan 28 00:38:28 They were spassing. Jan 28 00:39:04 that doesn't surprise me, but that's not the same as only one motor of the four working, which is what you claimed the problem was Jan 28 00:39:25 I feel bad for the people I contacted to see if it was them or me. Jan 28 00:39:29 Ha. Jan 28 00:39:35 just assume it's you Jan 28 00:39:38 I know. Not funny. Jan 28 00:39:39 it usually is Jan 28 00:39:39 Okay. Jan 28 00:39:41 I know. Jan 28 00:39:58 It is a good board again, i.e. Geaux Capes! Jan 28 00:40:28 I have to keep telling myself, "There is no crying in electronics." Jan 28 00:45:53 frying yes crying no Jan 28 00:47:23 oh and ds2: Once. Jan 28 00:47:32 Not head but finger. Jan 28 00:47:43 Right, no crying "yet." Jan 28 00:48:25 You know, "Blood, sweat, tears?" Jan 28 00:49:36 Now, back to basics so the children can participate in electronic basics, e.g. LEDs, buttons, and sensors/actuators. Jan 28 01:09:05 LEDs like the 10W UV LEDs? ;) Jan 28 01:11:15 No. Not yet. Jan 28 01:11:35 I know nothing about those (yet). Jan 28 01:12:59 ds2: *perk* ;P Jan 28 01:15:07 Ha, ha. Jan 28 01:15:12 bbl! Jan 28 01:18:39 veremitz: u have an app in mind? :D Jan 28 01:26:34 10W UV LED is kind of very dangerous then again so are normal spectra 10W LEDs "do not look into LED with remaining eye" Jan 28 01:28:42 that depends on your definition of UV Jan 28 01:28:53 a 290nm one, no arguments there. Jan 28 01:29:03 a 300nm is much less so Jan 28 01:29:08 oops Jan 28 01:29:11 390nm I mean Jan 28 01:29:18 or even 405nm "UV" Jan 28 01:39:41 ds2: just curiosity really, for special effects lighting :) Jan 28 01:46:43 veremitz: like black light stuff? Jan 28 01:47:15 xactly Jan 28 01:47:39 I've not really done enough with power LEDs yet .. I'm lagging behind :/ Jan 28 01:55:44 it isn't that different...just heat and more heat Jan 28 02:23:19 mostly heat Jan 28 02:24:03 the black light spectra is not as eye killing as higher order frequencies.Those have special filtering on them. Jan 28 02:26:09 ds2 well I suppose having worked in and industrial UV setting high power UV was considered very dangerous. Then again I'm talking 30KW not 10W. Still it's powerful enough to do some damage definitely don't look directly into an emitter. **** ENDING LOGGING AT Tue Jan 28 02:59:57 2020