**** BEGIN LOGGING AT Fri Jun 28 02:59:57 2019 Jun 28 23:20:24 @zmatt: It must be something else besides that small chip and changing the 5v to 3.3v (CD40109B). Jun 28 23:20:25 ... Jun 28 23:20:34 Oh well. I will keep testing. Jun 28 23:31:42 I mean...literally! The only thing I need to do, from what the ardupilot people say, is use their software w/ the BBBlue w/out writing extra software. Jun 28 23:31:42 ... Jun 28 23:32:29 I think this is the issue. Their software as is, cannot, does not work. I might like w/ most libraries have to write up some small software examples off their src. Jun 28 23:33:04 Anyway...back to basics. Jun 28 23:47:26 bbl Jun 29 00:44:54 set_: nah, pretty sure that's not true Jun 29 00:45:36 Oh? You mean...the src should allow for movement to the motors w/out extra code written? Jun 29 00:45:51 as far as I can tell you just need correct configuration Jun 29 00:45:56 Okay. Jun 29 00:46:00 and there are prebuilt binaries you can use Jun 29 00:46:15 which immediately indicates there's no need to customize the source code Jun 29 00:46:36 I noticed and I have them installed on the BBBlue. I followed Mirkix and imfatant on their introduction to the usage. Jun 29 00:46:38 Okay. Jun 29 00:47:07 prebuilt binaries...got it. I think I have these things working but who knows? Jun 29 00:47:26 I really have no way of judging their source b/c I could not type it up better. Jun 29 00:47:48 https://github.com/imfatant/test seems to have fairly detailed step-by-step instructions Jun 29 00:48:06 @zmatt: Yea. I looked it over and followed it precisely. Jun 29 00:48:29 Over and over while he has put in work over the course of two years. Jun 29 00:48:55 Not once have I gotten the motors to communicate from the ESCs. Jun 29 00:49:09 I tried w/ some simple software and boom! The motors were turning. Jun 29 00:50:59 Same hardware w/ a simple Arduino = motors turn w/ the ESCs. W/ the BBBlue and the arducopter set up = no turning motors. Jun 29 00:51:01 ... Jun 29 00:51:05 Not your issue. I know. Jun 29 00:51:25 I will try another day. Kaput! Jun 29 00:52:08 motors? moments ago you were still talking about the (x8r) receiver, not motors Jun 29 00:52:22 I know. Jun 29 00:53:04 I got the set up w/ my X8R, an Arduino, and the set up w/out the CD40109B to move those motors while my ESCs were attached. Jun 29 00:53:41 I cannot make the set up/wiring work w/ the BBBlue, ESCs, X8R, and the arducopter software. Jun 29 00:53:44 That is all. Jun 29 00:54:16 I have missed something vital. I am sure of it. Jun 29 00:54:26 try to get one part working at a time :P Jun 29 00:54:36 Nice idea. I will do that for now on. Jun 29 00:54:41 Ugh. Jun 29 00:55:28 Anyway...I have been back and forth on a bike (many hours). I can probably type for the next eight hours. So, I should read instead. Jun 29 00:59:06 looks like the "ground station" software for ardupilot has a function used to calibrate the RC controls, which can also be used to check whether you can receive the signal from the x8r (without trying to get any motors involved yet) Jun 29 00:59:14 http://ardupilot.org/plane/docs/common-radio-control-calibration.html Jun 29 01:03:22 Okay. I will try that again. I am pretty sure I already tried to "calibrate" the tx and the ESCs. Jun 29 01:03:29 Off to the site! Jun 29 01:04:13 also, level shifter is apparently not strictly required (but doesn't hurt and helps to protect your bbblue in case something wonky happens with power sequencing) Jun 29 01:04:47 Okay. Jun 29 01:05:13 I saw where the idea of Mirkix' ideas on PRU software make sure of that idea. Jun 29 01:05:27 the level shifter not being required. Jun 29 01:05:58 ?? Jun 29 01:06:04 I know. That came out funny. Jun 29 01:06:12 Sorry. Jun 29 01:06:16 Let me try again. Jun 29 01:07:07 You are right! ?? Jun 29 01:07:33 I do not know how in the hell the PRU is communicating to the rest of the board for ESC to motor communication. Jun 29 01:09:15 PRU just passes the raw signals to ardupilot (the precise mechanism doesn't matter, it's just an implementation detail of ardupilot), which then decodes the signal and does its thing with it Jun 29 01:10:31 My transmitter is not going to tell the receiver anything w/ my set up. I could probably take a photo when I set things up and you would laugh out loud (LOL) at the reasons on why nothing works. Jun 29 01:10:32 ... Jun 29 01:11:09 But...I keep believing that this PRU instance/input will tell ArduCopter that my tran. and rec. will communicate w/ the BBBlue as the brains. Jun 29 01:11:35 I need a brake, literally. A brain brake. Stop! Jun 29 01:11:55 I feel bad for the other people setting things up w/ their own hardware. Jun 29 01:12:59 Off the shelf, it seems like a nice idea. In the trench of ideas, arducopter is not user friendly (my experience). Jun 29 01:13:00 ... Jun 29 01:13:18 I should type up my own software. PRU...no. PWM...yes. GPIO...yes. Jun 29 01:13:31 It is four motors, sheesh. Jun 29 01:14:32 Maybe I can attach some drivers or something and put that old software you showed me to use again. Jun 29 01:14:35 set_: if you think your breadboard setup or whatever is at fault, try wiring it directly now that you know it's 3.3V. that only requires two wires (ground and the sbus signal). just make sure the beaglebone is powered up before you power up the x8r, and power down the x8r (or disconnect sbus) before powering down the beaglebone Jun 29 01:14:57 Okay. Jun 29 01:15:11 Tricky but doable. Jun 29 01:15:17 "tricky" ? Jun 29 01:15:37 The receiver is powered via the BBBlue. Jun 29 01:15:49 receiver = X8R Jun 29 01:15:57 okay, and? Jun 29 01:16:56 just make sure the beaglebone is powered before you connect the last wire to the x8r (either power or sbus) Jun 29 01:17:00 Too complicated. I need a quick fix, i.e. like something that says, "Yes set_, you have made it to arducopter flying land." Jun 29 01:17:01 Ha. Jun 29 01:17:07 Okay. Jun 29 01:17:08 Okay. Jun 29 01:17:12 I will try it. Jun 29 01:17:25 it's just for testing, to check whether ardupilot can receive the signal Jun 29 01:17:31 Right. Jun 29 01:18:08 So, get this. I will test/calibrate the tx and then try your idea out after calibrating the tx. Jun 29 01:18:15 if it's powered from the beaglebone it *might* also be safe to leave them connected Jun 29 01:18:22 Okay. Jun 29 01:18:27 assuming you're not using an always-on 5v source from the beaglebone Jun 29 01:18:51 Yea. The header, those servo pins, is always powered on for other devices. Jun 29 01:19:04 but I vaguely remember the bbblue mostly exposing always-on 5v outputs, which is a problem Jun 29 01:19:04 Hey @zmatt: I can try to power the receiver seperately. Jun 29 01:19:10 Right. Jun 29 01:19:26 i.e. not from the BBBlue. Jun 29 01:19:34 ??? Jun 29 01:19:38 what? Jun 29 01:19:40 I should have tried this already. Jun 29 01:19:55 also, the servo 6v output is indeed a good choice, I probably recommended that Jun 29 01:20:11 since it is not always-on, it needs to be explicitly enabled Jun 29 01:20:13 The receiver is powered via the servo output. Jun 29 01:20:39 Right. But, w/ my set up, the .service file powers the servo output on boot. Jun 29 01:20:53 I'd call it the servo supply, "servo output" since like a digital output rather than a 6v supply :P Jun 29 01:21:00 Okay. servo supply. Jun 29 01:21:01 yeah that's fine Jun 29 01:21:18 So, this servo supply... Jun 29 01:21:18 since obviously the beaglebone is properly powered up already at that time ;) Jun 29 01:21:27 Right. Jun 29 01:21:46 then yeah, then you only need three or four wires between BBBlue and x8r Jun 29 01:22:23 I have two sets of wires coming from my LiPo. Two (one set) for the BBBlue. The other set for the ESCs. Jun 29 01:22:40 Should I power the ESCs and motors via something more powerful? Jun 29 01:22:47 Probably...yea. Jun 29 01:22:48 (preferably four: even if the x8r is presumably already grounded as a result of being powered from the bbblue, it's a good idea to still explicitly include the ground wire from the sbus header to the E4 header) Jun 29 01:22:58 one problem at a time set_ Jun 29 01:23:02 Okay. Jun 29 01:23:03 no motors, just x8r Jun 29 01:23:10 I am bouncing still from the bike ride. Jun 29 01:23:16 Okay. Jun 29 01:23:24 just the X8R. Jun 29 01:23:52 So, the X8R... Jun 29 01:24:52 It can push the uart/rev. uart signal (SBus) to the BBBlue. I think, even though the ideas are circulating, the BBBlue should not take this 5v supply from the X8R. Jun 29 01:25:10 Right? Jun 29 01:25:17 I mean...that could cause trouble. Jun 29 01:25:20 Boom! Jun 29 01:25:25 or bzzt. bzzt. Jun 29 01:25:54 So, that is why I am using the X8R w/ this level shifter no matter what the source states. Jun 29 01:26:19 $80.00 for a flying BBB family board is not cheap but worth it if I keep it up and running for now. Jun 29 01:26:53 So, that is my plight on this ordeal. Jun 29 01:27:14 If it was $35.00 or $40.00, I would have tried everything already. Jun 29 01:27:42 That is why I used that BBG for so long. Jun 29 01:29:08 Outside of those ideas, I tried: https://pastebin.com/SmqYJkPs w/out the enable A pin used. Jun 29 01:29:22 I did use it for the new set up, though. Jun 29 01:30:56 Anyway...the set up you showed me worked, in this sense, and did not corrupt my board or cause damage. Jun 29 01:31:11 Luckily, what i did also did not cause any trouble. Jun 29 01:32:07 The board, the BBBlue, shows that the user, red LED, LED is on and running due to the compiled arducopter software. Jun 29 01:32:08 ... Jun 29 01:34:10 It boots w/ errors. I can run it w/out the .service file on boot and it states that there is something faulty. Faulty/errors state that the baro (barometer) is out or not calibrated. This is one error of many that could be doing this no ESC to motor communication. Jun 29 01:36:48 okay. Brake! Jun 29 01:42:55 set_: the x8r sbus signal isn't 5v, it's 3.3v Jun 29 01:43:02 NO. Jun 29 01:43:07 It is 5v. Jun 29 01:43:30 I already have the paperwork on it. It came w/ the receiver. Jun 29 01:43:41 operating voltage @ 5v. Jun 29 01:44:13 that's not talking about the voltage range of the sbus output signal Jun 29 01:44:20 Dang it. Are you serious? Jun 29 01:44:21 https://photos.app.goo.gl/JCXuD55PNsBxuptq6 this should be fine Jun 29 01:44:52 I will try it. Jun 29 01:45:12 yes, I repeatedly complained that there was no clear documentation on this, but mirkix apparently verified it is 3.3v Jun 29 01:45:25 I saw on the paperwork, oh... Jun 29 01:45:25 https://github.com/mirkix/ardupilotblue#tested-receiver Jun 29 01:46:10 I can test it before jumping into this river. Jun 29 01:46:33 I remember you saying/typing this info. out. Jun 29 01:46:44 You typed that there was no clear doc. on it. Jun 29 01:46:47 sure, if you have a scope to verify the signal voltage range of the x8r's sbus output then that's even better Jun 29 01:46:48 I will test it. Jun 29 01:46:59 I have a oscope. Jun 29 01:47:17 I need to fix it but it is just a screw to turn. Jun 29 01:47:26 but I don't see any reason to doubt mirkix Jun 29 01:47:36 he has stuff working evidently :P Jun 29 01:47:43 Right. Jun 29 01:48:31 @zmatt: Just like you, mirkix and I have not met in life. I rarely chat w/ him. I am not trying to disrespect you or tell you off by typing this idea out. Jun 29 01:48:39 ... Jun 29 01:49:32 I am hesitant to try things w/ a $80.00 board. I could easily make an error to that would amount to bzzt, bzzt. Jun 29 01:50:09 Anyway...I should test tonight while this idea is fresh in my mind. Jun 29 01:50:34 boggle brain over here will forget if it does not get done at least once. Jun 29 01:50:34 and yet you didn't double-check your power supply connections to the level shifter (which is one way you could easily have fried the blue) Jun 29 01:51:03 See. I get confused on things easily. You are smarter in this realm. You know it, I know it, and readers know it. Jun 29 01:51:32 So, I need to stay precautious when I am knowingly attempting circuitry. Jun 29 01:51:39 which is why I drew out the exact connections to hopefully eliminate any risk of confusion Jun 29 01:51:45 Thank you. Jun 29 01:51:49 YOu did and it helped. Jun 29 01:52:19 The board, BBBlue, is still in working order and I can thank you. Jun 29 01:52:38 you confirmed the E4.4 pin is still functional? Jun 29 01:52:51 Not yet. I need to try it. Jun 29 01:53:10 It is going to be difficult but I will test it now. Please hold. Jun 29 01:53:41 I will use one of those already-made connectors I purchased to test. Jun 29 01:53:47 brb Jun 29 01:55:42 you could also just switch between gpio_pu and gpio_pd and verify that the input value changes accordingly, this doesn't require any external connections Jun 29 02:02:37 328 +- ... mV Jun 29 02:03:00 Does this sound like 3.3v...yep. Jun 29 02:03:14 So, it may be as an output, right? Jun 29 02:03:38 uhh what? Jun 29 02:03:55 "328 +- ... mV Jun 29 02:04:01 I attached my oscope to the PRU and to GND. I got back that reading: 328 mV. Jun 29 02:04:18 ... <--- forget that Jun 29 02:04:20 to the extend I can parse that (which is barely), it would make no sense Jun 29 02:04:32 unless you forgot a zero Jun 29 02:04:36 Oh. Jun 29 02:04:54 and the pru? what? no? Jun 29 02:05:01 you were going to measure the x8r Jun 29 02:05:05 Oh. Right. Jun 29 02:05:07 Dang it. Jun 29 02:05:20 though reading 328 mV *anywhere* is very weird Jun 29 02:05:39 Okay. Jun 29 02:06:21 That is what I thought. I just figured it meant at 100 Hz, 328 mV means 3.3v or close to it. Jun 29 02:06:56 also please be more precise with your words, you can't attach a scope to "the PRU", it's inside the AM335x. if you meant pin E4.4, then say that Jun 29 02:06:59 "at 100 Hz" ?? Jun 29 02:07:21 328 mV is 0.328 V, which is not (remotely) 3.3V Jun 29 02:07:26 I know. Jun 29 02:07:28 This is odd. Jun 29 02:07:40 Oh. Jun 29 02:07:46 Okay. Pin e4.4 Jun 29 02:07:59 and what did you mean by "at 100 Hz" ? Jun 29 02:08:00 I will test the pin again. Jun 29 02:08:20 I can change my testing range from 100 Hz to 200 Hz to 500 Hz. Jun 29 02:08:25 or 50 Hz. Jun 29 02:08:44 Okay. So, right now... Jun 29 02:08:46 ?? Jun 29 02:08:49 "testing range" ? Jun 29 02:09:09 @zmatt: I do not know what to call it right now. I am sorry. Jun 29 02:09:29 I have been up to my ears in poo. Let me catch a break. Jun 29 02:10:03 I will go and read the entire doc. before talking to you. Please forgive me. Jun 29 02:10:32 I just don't understand what a frequency of that order of magnitude could *possibly* be referring to in this context Jun 29 02:10:42 doc? of the scope? Jun 29 02:11:03 Yes. Jun 29 02:11:32 I will read exactly what that scope means when changing those Hz figures. Jun 29 02:11:50 oh wait I see how you managed to confuse me Jun 29 02:12:41 OH...Sorry. Jun 29 02:12:48 since you were talking about a voltage measurement I assumed you meant the x8r sbus output, but given that the topic was about whether the e4.4 pin is still function you seem to be confused about the test needed Jun 29 02:12:54 since no scope is involved in that Jun 29 02:13:03 Oh. Dang. Jun 29 02:13:06 Right-o. Jun 29 02:13:34 Okay. I will test the E4.4 pin and gnd it w/ a multimeter and then test w/ the Oscope on the receiver. Jun 29 02:13:50 Boy! Jun 29 02:13:52 multimeter? Jun 29 02:13:53 Yea, yea/ Jun 29 02:14:00 Then what should I use? Jun 29 02:14:34 What test should I give it? Jun 29 02:14:42 either a wire (to pull it up to 3.3v or down to gnd) or nothing but software config (if you use config-pin modes gpio_pu and gpio_pd to pull the pin up/down instead) Jun 29 02:15:05 the latter is probably easiest and least error-prone Jun 29 02:15:22 The software is running. I would have to alter the software and stop the .service file, right? Jun 29 02:15:34 for the arducopter stuff. Jun 29 02:15:36 i.e. configure it to gpio_pu, confirm the gpio value reads as 1, configure the mode to gpio_pd, confirm the value reads as 0 Jun 29 02:15:46 Okay. Jun 29 02:16:05 W/ the arducopter .service file running or w/ that .service file disabled and stopped? Jun 29 02:16:36 I'd stop arducopter but it probably doesn't matter Jun 29 02:16:45 B/c that service file runs that pin. Jun 29 02:16:46 Okay. Jun 29 02:17:14 brb Jun 29 02:17:32 if you configure it to gpio mode, pru (and therefore arducopter) won't see any signal on that pin anymore Jun 29 02:19:05 Okay. I understand. Jun 29 02:19:31 Do I just use config-pin? Jun 29 02:19:49 so, config-pin gpio_pu gpio? Jun 29 02:20:04 then...config-pin -q gpio_pu? Jun 29 02:20:45 config-pin $PIN gpio_pu where $PIN is whatever config-pin's name is for the E4.4 pin (no idea) Jun 29 02:20:55 Oh. Okay. Jun 29 02:24:44 PR1_PRU0_PRU_R31_15 seems to be the pin or should I use qep_4b? Jun 29 02:25:13 neither sounds like a name config-pin will accept Jun 29 02:25:24 bingo! Jun 29 02:25:36 GPIO1_15? Jun 29 02:25:37 but I don't use config-pin myself so *shrug* Jun 29 02:25:44 aw! Jun 29 02:26:30 if you're in doubt whether you configured the right pin (or about which gpio it is), use my show-pins script to check the config of E4.4 Jun 29 02:26:51 it will also show the gpio's state Jun 29 02:27:50 Okay. Hey...I have been unable to config-pin anything so far. I will keep trying. Jun 29 02:29:48 what does show-pins say about the config of E4.4? Jun 29 02:30:08 pretty sure you can also find the pin name for config-pin in there Jun 29 02:30:33 Okay. Jun 29 02:30:38 I will look at both. Jun 29 02:31:15 Should I look under mvduin again for that show-pin utility? Jun 29 02:33:13 you don't have it installed yet? :P Jun 29 02:33:25 https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Jun 29 02:33:33 (that's the bbblue version) Jun 29 02:34:01 Oh. Jun 29 02:34:06 I figured something was incorrect. Jun 29 02:35:19 Can't open /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins: No such file or directory at /usr/local/sbin/show-pins line 54. Jun 29 02:35:22 this is the error. Jun 29 02:35:40 uhh what? Jun 29 02:35:47 which kernel version? Jun 29 02:35:48 Serious. Jun 29 02:35:54 Please hold. Jun 29 02:35:58 I will check. Jun 29 02:36:18 4.19.50-bone-rt-r35 Jun 29 02:36:44 I know, I know. Jun 29 02:36:51 I should not have this kernel version. Jun 29 02:36:53 if something changed in 4.19 that broke show-pins then I'd need to look into that. you're the first to report any problems with it Jun 29 02:37:01 Okay. Jun 29 02:37:11 Let me stop this .service file. Jun 29 02:37:26 Maybe it is the damn service file running every resource I have now. Jun 29 02:38:22 NOpe. Jun 29 02:38:25 Same thing. Jun 29 02:40:59 this isn't affected by anything you're doing, it's purely the specific kernel used Jun 29 02:41:18 I think show-pins so far has required updating for every major new kernel series Jun 29 02:41:19 Okay. Jun 29 02:41:34 So, nothing I did on my end caused this issue. Finally. Jun 29 02:41:39 config-pin calls E4.4 "P8_15" btw Jun 29 02:41:44 Oh. Jun 29 02:41:51 Okay. That is funny. Thank you. Jun 29 02:42:25 yup, I'd personally have been more inclined to call it... you know.. E4_4 ... but hey that's me :P Jun 29 02:43:02 P8_15 Mode: gpio_pu Direction: pin_not_exported Value: pin_not_exported Jun 29 02:43:06 That is what came back. Jun 29 02:43:44 I think we are on to something now. Jun 29 02:43:49 My pin cannot be exported. Jun 29 02:44:37 it doesn't say that, it just says it *isn't* exported, which is a bit of an oversight but not really a problem Jun 29 02:45:07 Oh. Jun 29 02:45:17 echo 47 | sudo tee /sys/class/gpio/export Jun 29 02:45:22 Okay. Jun 29 02:46:03 then check its value with 'cat /sys/class/gpio/gpio47/value' or using config-pin Jun 29 02:46:28 0 on both Jun 29 02:46:45 I did gpio_pd first. Jun 29 02:47:05 0 is expected for gpio_pd, 1 is expected while in gpio_pu mode Jun 29 02:47:32 1 is gpio_pu. Right. Jun 29 02:47:33 Okay. Jun 29 02:47:43 So, nothing odd there I will guess. Jun 29 02:48:08 I can change the mode in that pin? Jun 29 02:48:09 Odd. Jun 29 02:48:17 if you've confirmed both, then that concludes the test Jun 29 02:48:24 the pin is physically fine Jun 29 02:48:27 I figured since it was a BBBlue, things were set in stone. Jun 29 02:48:30 Okay. Great. Jun 29 02:48:50 why would they be set in stone? many pins have multiple possible functions Jun 29 02:48:56 Physically...things seem to be working just fine. Good. Jun 29 02:48:58 Well... Jun 29 02:49:04 The BBBlue is a different machine. Jun 29 02:49:21 It has hard to reach pin connects. Jun 29 02:49:44 ? Jun 29 02:49:49 I figured that you all over in BBB land would have set things up to just work one way. I guessed incorrectly. Jun 29 02:50:01 @zmatt: Do not worry about that idea. Jun 29 02:50:29 @zmatt: What do you think of the issue now, i.e. now that we can conclude on the pru output and input? Jun 29 02:50:41 Well...the pin that is. Jun 29 02:51:25 I think you should connect the x8r as indicated in my latest sketch and see if you can confirm ardupilot is able to receive its signals Jun 29 02:51:27 I keep getting the pru instance and the pin confused. Sorry. Jun 29 02:51:33 Okay. Jun 29 02:51:42 I can do it. Jun 29 02:51:44 Please hold. Jun 29 02:51:46 brb Jun 29 02:52:39 make sure the pin is in pruecapin_pu mode. hopefully ardupilot will take care of that, but do double-check that Jun 29 02:53:03 at least I think it uses that mode Jun 29 02:53:41 dang. Jun 29 02:53:49 yeah it does Jun 29 02:53:55 We just took it out of prucapin_pu mode. Jun 29 02:54:07 for testing the pin, yes Jun 29 02:54:16 So, I need to put it in prucapin_pu mode. Jun 29 02:54:18 Okay. Jun 29 02:54:43 "prucapin" that sounds like a tiny dog breed Jun 29 02:55:02 Basically. Jun 29 02:55:22 @zmatt: that is an invalid assisgnment on that p8.15 pin. Jun 29 02:55:36 no it's not Jun 29 02:55:44 assisgnment = assignment/pin adjustment Jun 29 02:55:57 I just tried it. Jun 29 02:56:05 you probably made a typo Jun 29 02:56:30 w/ config pin or do I need to use echo and then check w/ cat? Jun 29 02:57:10 uh, whatever you want? Jun 29 02:57:49 if doing it manually works but config-pin doesn't then you should do a bug report for config-pin Jun 29 02:58:11 Okay. Jun 29 02:58:38 I tried config-pin p8.15 pruecapin_pu Jun 29 02:58:53 invalid mode Jun 29 02:59:01 That must be it. Jun 29 02:59:02 could be a bug in config-pin Jun 29 02:59:09 Probably. Jun 29 02:59:24 try echo pruecapin_pu | sudo tee /sys/devices/platform/ocp/ocp:P8_15_pinmux/state Jun 29 02:59:42 and confirm with cat /sys/devices/platform/ocp/ocp:P8_15_pinmux/state **** ENDING LOGGING AT Sat Jun 29 02:59:57 2019