[00:00.000 --> 00:06.200]  working in conjunction here with Daryl and team to produce some of these labs and whatnot.
[00:06.440 --> 00:11.440]  And this particular one is going to be about logic analyzers. So, my name is Jonathan Sines.
[00:11.440 --> 00:18.720]  I'm a pen tester on the Rapid7 team. And just to dive right in, what is the purpose of a logic
[00:18.720 --> 00:26.310]  analyzer? So, in essence, developers use logic analyzers pretty heavily for doing things such as
[00:27.990 --> 00:31.310]  debugging protocols. So, if they're doing something like what we see in the picture
[00:31.310 --> 00:37.330]  here that has probably some form of interchip communication, maybe there's like SPI or I2C,
[00:37.330 --> 00:43.230]  logic analyzers enable you to dig down and see underneath the hood what's actually going on.
[00:43.230 --> 00:48.210]  Works fantastically for troubleshooting. Just think like Wireshark for hardware analysis.
[00:48.790 --> 00:53.810]  Like I was mentioning, it could also be used to debug. So, it's used to troubleshoot maybe
[00:53.810 --> 01:00.030]  why is my software not working? Why is this embedded firmware not talking from the SPI
[01:00.030 --> 01:05.070]  flash chip to my MCU? A logic analyzer can kind of help troubleshoot that.
[01:05.070 --> 01:12.670]  So, that's the sort of developer-y perspective of using a logic analyzer. Now,
[01:12.670 --> 01:19.950]  how would we use them in IoT? So, of course, we have the pizza delivery, pizza doom guy,
[01:19.950 --> 01:28.870]  with the ski mask underneath. We use them in IoT. Our goal is to dump the firmware. So,
[01:29.390 --> 01:34.590]  once the firmware is dumped, it's oftentimes mostly dumped through serial interfaces,
[01:34.590 --> 01:38.450]  unless we're doing something like removing a chip. So, whenever we're talking about this,
[01:38.450 --> 01:43.150]  it's going to be more so focused on from the perspective of doing something like dumping
[01:43.150 --> 01:49.930]  firmware from some type of interface, whether that be UART, whether that be SPI, whether that be I2C.
[01:49.950 --> 01:55.510]  Also, it's to interact with the device. I know that if you've attended any of our other talks
[01:56.990 --> 02:02.250]  from today with regard to U-Boot or any of the talks yesterday, we've talked a lot about UART.
[02:02.250 --> 02:07.250]  So, UART will be the serial, I guess, mechanism that we would use to interact with some of these
[02:07.250 --> 02:14.170]  devices. So, what we want to do is identify what is the pinout of some of these devices. And we'll
[02:14.170 --> 02:20.090]  talk a little bit more about that later on in the slides here. But a lot of times, the pins,
[02:20.090 --> 02:27.630]  they're not labeled. So, we need to figure out, okay, A, what type of protocol is being used for
[02:27.630 --> 02:32.750]  these pins? And B, which individual channel is being sent or what kind of data is being
[02:32.750 --> 02:41.090]  transported over those pins? So, things such as you can check things on a simple serial bus,
[02:41.090 --> 02:46.730]  like SPI, I2S, I2C, UART, things like that using a logic analyzer.
[02:48.970 --> 02:53.070]  What are the types of logic analyzers? Again, I know we're kind of talking about maybe some
[02:53.070 --> 02:57.310]  boring stuff, but just to kind of take you a little bit back in time here, the bottom left
[02:57.310 --> 03:01.410]  corner is a desktop logic analyzer. You don't really see those that much these days. That looks
[03:01.410 --> 03:06.290]  more like an oscilloscope, but it's, in fact, a logic analyzer. If you kind of take a closer look,
[03:06.290 --> 03:10.950]  you can see that it's actually measuring digital frequencies, something that an oscilloscope does
[03:10.950 --> 03:16.430]  not do, which we'll talk about more later. What we will be talking about and looking at in our
[03:16.430 --> 03:22.950]  demos is going to be USB logic analyzers, and those look more like the things you see on the
[03:22.950 --> 03:27.570]  right side of the screen. So, the Saley is like one of the more popular ones, and you have a couple
[03:27.570 --> 03:33.790]  of the others, like Travelogic in this particular case. The USB analyzers tend to be cheap,
[03:33.790 --> 03:39.570]  and they tend to be small. Desktop analyzers tend to be large, and they tend to be expensive.
[03:39.570 --> 03:46.870]  We'll talk also a little bit about oscilloscopes later, but the logic analyzer has a small amount
[03:46.870 --> 03:51.990]  of memory, but a large number of channels. That's pretty important, because we'll kind of compare
[03:51.990 --> 03:56.830]  and contrast what might be right for you. If you're wanting to get started with some of this stuff,
[03:56.830 --> 04:01.350]  what would be best for you with what you're doing with whatever it is that your goal is.
[04:01.750 --> 04:06.490]  Logic analyzer is a visual representation of the data that it processes as well. So,
[04:06.490 --> 04:12.290]  when I say that it's a visual representation, it's making the calculation and representing
[04:12.290 --> 04:17.390]  what it thinks is what that data looks like, rather than oscilloscope, which is the actual
[04:17.390 --> 04:23.270]  analog signals that's traversing over the voltages of the chip.
[04:24.630 --> 04:29.030]  These logic analyzers, we'll talk about price later, but like I was mentioning earlier,
[04:29.030 --> 04:37.170]  USB logic analyzers tend to be very cheap. Okay, a logic analyzer is not an oscilloscope.
[04:37.170 --> 04:43.910]  So, all these snippets I stole off the Salie website. The oscilloscope,
[04:43.910 --> 04:48.910]  it measures... the idea in general is that it's measuring constantly. It's not like...
[04:49.630 --> 05:01.800]  This is quite possibly the most boring slide I've had, so it sucks to be y'all.
[05:02.780 --> 05:12.440]  I'm just kidding. They're all equally bad. So anyways, oscilloscope is not a logic analyzer.
[05:12.440 --> 05:19.900]  Oscilloscope measures analog, whereas logic analyzers measure digital. I'm actually glad
[05:19.900 --> 05:26.880]  we went back to this one, because some logic analyzers can actually measure analog. We'll
[05:26.880 --> 05:30.280]  talk about that a little bit later. I'll kind of show you. We'll go over a few different logic
[05:30.280 --> 05:36.980]  analyzers, just to kind of see what... but I probably shouldn't just use like the blanket
[05:36.980 --> 05:44.600]  statement and say that logic analyzers cannot measure analog, because that's not a true
[05:44.600 --> 05:48.860]  statement. They can to a certain extent, but many of them do not.
[05:51.630 --> 05:59.090]  So as I was mentioning, they are not used for any type of like UART connection. So you get data
[05:59.090 --> 06:05.030]  being transmitted over UART, but you can't actually set up like, okay, hey, I want to
[06:05.030 --> 06:10.710]  toss in like, you know, let's connect to this using 8-bit, you know, parity, and then we'll
[06:10.710 --> 06:16.890]  of course do like a quadrate of like 11200 and interact with this device. That's not what you
[06:16.890 --> 06:21.890]  can do with a logic analyzer. Logic analyzer is more of just a passive listener. It's something
[06:21.890 --> 06:31.830]  like Wireshark or hardware. It's not an oscilloscope. So from an oscilloscope perspective,
[06:32.530 --> 06:40.950]  basically you're looking at voltages over a period of time. So it uses memory. So it's using,
[06:40.950 --> 08:15.710]  say, for OCD. So we have the Sabley, right? So the Sabley is, I don't want to say de facto,
[08:15.710 --> 08:25.030]  but it kind of is de facto. It's also some software and a pretty large online community
[08:25.400 --> 08:32.350]  and support that is available that goes hand in hand with this particular logic analyzer.
[08:32.350 --> 08:38.250]  There are other logic analyzers, of course, that exist and we'll look a little bit more
[08:38.250 --> 08:43.910]  about the prices. What did we pay for these? Between like 5 and 15, 20 bucks.
[08:43.910 --> 08:48.430]  I think it was like 12 for one and 24 for the other one.
[08:48.430 --> 08:55.650]  Very cheap, you know, like go sell like a garbage bag full of, you know, aluminum cans and then buy
[08:55.650 --> 09:03.050]  this stuff because you can just, it's just outrageously cheap. So anyways, we'll do some
[09:03.050 --> 09:07.830]  pros and cons between all these guys, but we're going to kind of just, let's just go ahead and
[09:07.830 --> 09:13.730]  hook something up with it. What we're actually going to look at with it is going to be Raspberry
[09:13.730 --> 09:24.550]  Pi. What we're going to look at also with it is Raspberry Pi has a UART interface. I'm sure as
[09:24.550 --> 09:33.810]  many of you guys know. And I'm going to try to just take the examples just to kind of give you
[09:33.810 --> 09:42.250]  an idea. But here is the Raspberry Pi like sort of coming out and hopefully everyone can see that.
[09:42.250 --> 09:48.630]  Daryl, is this showing up on the screen? Yes. Okay, perfect. So whenever you're looking at it,
[09:48.630 --> 10:02.390]  it's basically how it's laid out. So just be aware that it looks good. Cool. So as you can see
[10:02.390 --> 10:13.690]  on the screen, we have ground, several grounds. And then right here on these two, we have Rx and Tx.
[10:13.690 --> 10:20.950]  So Rx and Tx are the two interfaces that we're going to target for UART. So if we count down
[10:20.950 --> 10:28.090]  one, two, three, four, it is Rx or Tx rather. And then one, two, three, four, five, it's Rx.
[10:28.570 --> 10:32.590]  And then we'll have a ground down here in the bottom left-hand corner. So let's get this
[10:32.590 --> 10:41.010]  hooked up. I'm going to start this off with you guys with the, I guess just the matter in this
[10:41.010 --> 10:47.250]  particular case. But whenever you look at the actual like logic analyzer, you can see that
[10:47.250 --> 10:55.710]  there's like a mapping of the pins on it as well. So it's basically like channel zero through seven.
[10:55.710 --> 11:02.110]  And then there's two grounds. And what that's based off of is the actual like layout of the
[11:02.110 --> 11:08.350]  pins on the thing, and then you have the actual pins. So what we'll do is we'll take these three
[11:08.350 --> 11:15.410]  jumper wires here, and we're going to actually get rid of the old Raspberry Pi pinout graph.
[11:15.410 --> 11:21.790]  We're actually just going to move it over that way. And then we're going to just kind of hook
[11:21.790 --> 11:25.650]  these suckers up. You know what I mean? So we'll take ground. We're just going to use black. We'll
[11:25.650 --> 11:31.990]  try to be correct with our color usage here. Black for ground. So we'll hook that up to one
[11:31.990 --> 11:41.360]  of the two grounds there. And we'll hook up white to channel zero. And we'll hook up this like
[11:41.360 --> 11:47.500]  silver color to channel one. And if you guys think this is fun watching me do this, just wait
[11:47.500 --> 11:55.180]  until we get to the SPI. So that's exciting. I'm looking forward to it. And then as we saw earlier
[11:55.180 --> 12:00.700]  with the ground, this is the bottom left hand corner pointer here. Remember we hooked up white
[12:01.300 --> 12:08.960]  to channel zero. We're going to hook white up to channel... it's the fourth pin, so we'll use the
[12:08.960 --> 12:19.580]  TX here. And we'll hook up this little silver to RX. And that's it. So that is pretty much how
[12:19.580 --> 12:26.580]  these hook up. And we'll look at several other devices, but I just wanted to give everyone an
[12:26.580 --> 12:33.360]  idea so we're not kind of, you know, functioning in the dark here. So let's put a pin in this and
[12:33.360 --> 12:41.060]  let's circle back to some of the slides here. So we now know what that looks like. Now I've done a
[12:41.060 --> 12:48.060]  lot of talking here. I think we have a couple questions here. Let me look. There was one
[12:48.400 --> 12:52.780]  question. You may have already covered it, but I want to make sure it's asked. It's in the channel.
[12:52.780 --> 13:00.420]  Are there any equipment models that you can do experience to come across any models of devices
[13:00.420 --> 13:09.440]  like that? Yeah, so some do have the capability of doing both analog and digital. Most of the cheaper
[13:09.440 --> 13:17.140]  ones are only digital. Now the ones that support analog and digital are typically a little bit more
[13:17.140 --> 13:24.900]  expensive. And a great example of that is the Salee. It supports both and a channel.
[13:25.800 --> 13:31.260]  But yeah, so some models do support it. Typically you'll be paying a little bit more money for it.
[13:31.260 --> 13:38.180]  So I would definitely ask yourself, is analog something I truly need for the type of
[13:38.180 --> 13:44.180]  debugging, the type of troubleshooting, the type of development, or the type of hacking that I'll be
[13:44.180 --> 13:55.920]  doing. One other question here. So where can somebody buy the cheaper logic analyzers that
[13:55.920 --> 14:07.920]  you're demoing here? And would they work for newer to IoT versus having a larger investment?
[14:07.920 --> 14:19.760]  That is a very well-timed question. This is a couple examples of where you can get some of
[14:19.760 --> 14:26.080]  these logic analyzers. On the left side of the screen, I pulled this directly from the Salee
[14:26.080 --> 14:32.200]  website. Again, these are the nicer models that support both analog and digital. I'll also show
[14:32.200 --> 14:37.740]  everyone here on the call what it looks like and what it means to actually have a nicer one versus
[14:37.920 --> 14:45.860]  not so nice one. So are you going to be spending, in this case, an example to have on screen, $13 to
[14:45.860 --> 14:53.600]  $24? Or you can have a peek at that. But on the left side of the screen here, the pricing is from
[14:53.600 --> 15:01.820]  Salee. You can buy them on Amazon. You can buy them on eBay. You can buy them on Spark. The
[15:01.820 --> 15:09.700]  prices on the right, the two cheap ones below and above the dude whose wallet is on fire,
[15:09.700 --> 15:15.780]  were off Amazon. I had this screenshot of that maybe like three or four days ago.
[15:16.100 --> 15:22.200]  As far as the features between differences in between the cheaper one versus the more
[15:22.200 --> 15:29.820]  expensive one, we'll take a peek at that in a couple of demos, a few slides down the road.
[15:29.820 --> 15:32.920]  No more questions. I guess you can move on.
[15:33.340 --> 15:41.920]  Sweet. So moving on here, as I talked about earlier, the signaling.
[15:43.060 --> 15:49.220]  Analog signaling is just continuous changing values, whereas digital is defined values
[15:49.220 --> 15:56.600]  based on a range of voltage that we're going to see with these USB logic analyzers.
[15:57.240 --> 16:03.160]  Bear in mind, it's not 100% accurate. So if you're like needing to be like pinpoint accuracy
[16:03.160 --> 16:09.760]  on voltages, the logic analyzer is going to be... I also want to share with you what those digital
[16:09.760 --> 16:16.120]  versus analog signals look like. So whenever we dive into the software here pretty soon,
[16:16.120 --> 16:20.860]  we can kind of see what those waveforms are and how they differ from one another.
[16:21.240 --> 16:29.420]  The voltage above a certain threshold is... and digital signaling with logic analyzers
[16:29.420 --> 16:36.380]  is binary. If it's going low, then that's considered a zero. If it's going high,
[16:36.380 --> 16:43.540]  it's considered a one. And that determination is based upon that particular threshold transistor
[16:43.540 --> 16:51.740]  the technology is basically using. Logic analyzer will sample the voltages at various intervals and
[16:51.740 --> 16:57.540]  reconstruct what that data looks like. So I just want to kind of just shine a little bit of context
[16:57.540 --> 17:08.580]  as to analog versus digital. So there's two main types that I've used in my experience.
[17:08.580 --> 17:15.900]  Your mileage may vary. I know there's a lot of different other software, I guess, vendors,
[17:15.900 --> 17:22.940]  makers out there. I'm Mac-based, so I'm going to handcuff the Mac, fortunately, because it would
[17:24.460 --> 17:32.560]  also be capable of running on Linux, too. So the top left corner is Sigrock's PulseView.
[17:32.560 --> 17:37.680]  So Sigrock is a manufacturer of logic analyzer as well as software,
[17:37.680 --> 17:44.000]  and PulseView is the actual software name. Now, what we're going to talk about actually has
[17:44.000 --> 17:51.340]  Sigrock client, and I'll be honest with you, I love the fact that they're open source. I love
[17:51.340 --> 17:57.320]  the fact that it's free. Actually, both the software here is free, but the PulseView,
[17:57.320 --> 18:04.640]  the graphical interface, is just not the greatest. It's more robust, I guess you could say. So
[18:05.240 --> 18:08.800]  unfortunately, I'm not going to go over it today because it would probably take a little bit too
[18:08.800 --> 18:15.560]  much time. But to kind of dive in here, what I wanted to do was just kind of compare these two
[18:15.560 --> 18:22.980]  software sets with you. So with that being said, let's just dive right in. Let's just take a look
[18:22.980 --> 18:33.640]  here. Screw it. So what I want to do first is I want to continue with where we left off with
[18:33.640 --> 18:39.920]  this particular logic analyzer and the more expensive stuff. How about that? We've got a
[18:39.920 --> 18:47.260]  couple of wires here. We've got a power for the Raspberry Pi sitting right here. I have the USB
[18:47.260 --> 18:52.280]  power stripped here. I'm just going to kind of power off the Pi real fast. And we'll go ahead
[18:52.280 --> 19:00.560]  and grab the other cable for our logic analyzer. That's right there. Let's go ahead and plug this
[19:00.560 --> 19:12.160]  up. Now, as we're doing this, again, this is going to power for the logic analyzer.
[19:12.500 --> 19:23.770]  And what we're going to do next is let me... there we go. Okay, cool. We'll do that here.
[19:23.770 --> 19:28.450]  So I'm going to bring up the software on the other side of the screen here for us.
[19:29.570 --> 19:32.590]  And the first one we're going to look at is PulseView. So I just want to kind of
[19:32.590 --> 19:39.010]  give you a quick little demo of what some of this looks like. So as you can see here,
[19:39.530 --> 19:42.790]  shift that that way, we have everything hooked up on this side of the house.
[19:43.270 --> 19:49.950]  Remember, we have UART. So RXTX hooked up to this based off the pinout that we found online. And,
[19:49.950 --> 19:54.570]  of course, ground's hooked up as well. We followed the mappings here. So we're going to kind of take
[19:54.690 --> 19:58.550]  a white box approach with this. And let's just assume that we know everything already. So let's
[19:58.550 --> 20:01.910]  assume that we found the data sheet for the device that we're wanting to kind of probe and take a
[20:01.910 --> 20:07.370]  look at. What we want to do next is from the software here, I'll give you a quick little run
[20:07.370 --> 20:14.430]  through. So we'll go back to the full screen. This is the Sigrot PulseView. So with the PulseView,
[20:14.430 --> 20:18.050]  you can select the device you have plugged into your computer. And this particular one,
[20:18.050 --> 20:23.890]  the driver that we need is the FX2LAFW. So we'll select that from the dropdown,
[20:23.890 --> 20:28.070]  and we'll click scan for devices using the driver above. And then we'll click OK. And
[20:28.070 --> 20:34.070]  that basically has it hooked up. So what happens here is an airplane flying above here. So you'll
[20:34.070 --> 20:39.370]  hear some background to that. What you see here is that there's eight channels starting at zero
[20:39.370 --> 20:46.750]  and ending at seven. So that's representing the eight channels that the logic analyzer has.
[20:46.750 --> 20:54.170]  Remember, it's zero through seven on the logic analyzer. What we can do is we can lower that
[20:54.170 --> 20:58.530]  because we're only using RX and TX. Ground is assumed. You're always going to use ground. So
[20:58.530 --> 21:03.210]  we want to select D0 and D1. So we're going to remove some of these other guys here.
[21:03.590 --> 21:08.690]  Going back to the software here, you can change the amount of sampling that it does. In this
[21:08.690 --> 21:17.370]  particular case, I have it set at one millisamples per second. So that's the setting for that. And
[21:17.370 --> 21:21.670]  we'll talk about that a little bit more whenever we get into salient software. But the cheaper
[21:21.670 --> 21:27.050]  logic analyzers can sample at a slower rate than the Salie. So there's a little bit of a
[21:27.050 --> 21:31.710]  limitation here. And here's the speeds as well. So we're going to stick 20 kilohertz.
[21:31.710 --> 21:36.950]  So let's just plug this sucker in. Let's just see what happens. So I'm going to hit the power
[21:36.950 --> 21:41.910]  button. We're going to see the lights come on on the Raspberry Pi right here. And then I'm going
[21:41.910 --> 21:46.610]  hit the run button. Whoopsie-daisy.
[21:49.030 --> 21:56.630]  Try that again. And then we can click this button here, which makes us keep up with the timing of
[21:56.630 --> 22:04.750]  the actual logic analysis that's taking place. So we'll see some spikes and voltages as things
[22:04.750 --> 22:11.270]  happen. Again, this is over UART. So think of the TTY connection over some type of serial or
[22:11.270 --> 22:15.910]  SSH interface. Imagine just a boot up of a Raspberry Pi. So it's just going to do its crap.
[22:15.910 --> 22:20.230]  And then at the end, it's going to be like, okay, Raspberry login type stuff. So we'll go ahead and
[22:20.230 --> 22:29.250]  stop it now that we're getting kind of closer towards the end here. Yeah, that's the last one.
[22:29.250 --> 22:35.470]  So if we take a look here, this is basically the capture. I captured for, as you can see,
[22:35.470 --> 22:41.250]  35 seconds. So the thing about this, let's go ahead and go back into full screen. We don't
[22:41.250 --> 22:45.850]  really need the camera so much right now, but we'll go ahead and expand everything back out.
[22:45.850 --> 22:50.850]  And let's just take a look over here because this is the, let's just pretend again, let's just assume
[22:50.850 --> 22:54.730]  that we know the answer to this. This is basically where it's just prompting for a login to the UART
[22:54.730 --> 23:03.570]  interface. So we'll go in here and we'll kind of scroll, scroll, scroll. And even if you were unsure
[23:04.130 --> 23:10.290]  of which one was RX or TX, you could pretty well assume if you at least knew that these two
[23:10.290 --> 23:15.070]  connections were UART, that this one's going to be TX and this one's going to be RX. How is that?
[23:15.070 --> 23:21.170]  Because TX is sending us data and RX is literally a flat line. So a couple of things there that can
[23:21.170 --> 23:27.590]  kind of help you out. And one other thing too, is that this particular software does have protocol
[23:27.590 --> 23:34.210]  debuggers. So let's take a look at that and let's go ahead and remember we set TX to D0 and we set
[23:34.210 --> 23:40.650]  RX to D1. So another thing too, we already have 11.5.200. We're going to keep everything else
[23:40.650 --> 23:49.730]  basically default here. The least significant bit first is correct. We'll switch that to ASCII
[23:49.730 --> 23:57.570]  and it will come in here and then it should do some decoding for us. Usually it takes a second.
[24:01.000 --> 24:15.970]  Let's see if she works here. Yeah, so again, just a high-level example of the protocol decoding
[24:15.970 --> 24:22.010]  available for this particular PulseView software and some of the stuff you can do. So it recognizes
[24:22.010 --> 24:26.850]  stop bits, it recognizes frame errors, break conditions, things like that. Now what I want to
[24:26.850 --> 24:32.870]  also do real quick, we'll just exit completely out of here. We don't want to save. Another thing
[24:32.870 --> 24:38.870]  is it's pretty nifty. PulseView has SIGROC. They have their own proprietary format where you can
[24:38.870 --> 24:44.610]  save your data and then import it into Saly or other. You can manipulate it also from the command
[24:44.610 --> 24:53.730]  line. We want to now switch over to the Logic software from Saly. So Saly has their own set
[24:53.730 --> 24:57.770]  of software. They actually have two sets of software that we're going to review. And what I
[24:57.770 --> 25:11.680]  want to do is... let me open it up here. And what I want to do is show you guys both sets of
[25:11.680 --> 25:19.360]  software to kind of show you the epicness of what it has the capability of doing. So on the left-hand
[25:19.360 --> 25:28.420]  side here, we have the Saly Logic 1.0, 1.2.18 software, I guess, technically. And in this
[25:28.420 --> 25:34.860]  case, it's very similar. So remember, here's all the eight channels. And that's pretty much the
[25:34.860 --> 25:38.700]  situation that we're looking at. Mind you, remember, this is all digital signaling. So
[25:38.700 --> 25:47.400]  there's no actual analog signals going on in this particular case. So very similar to the other
[25:47.400 --> 25:53.420]  software, you can do the same protocol analysis. So we have, for instance, AsyncSerial, which is
[25:53.420 --> 25:59.840]  UART. UART is an AsyncSerial communication protocol with I2C and SPI. So there's a whole
[25:59.840 --> 26:05.360]  list of different protocols supported also by the Saly software. Your decoded protocols,
[26:05.360 --> 26:09.820]  it can actually decode also. As we saw earlier with the other software, it decoded it, but it's
[26:09.820 --> 26:13.720]  kind of limited on the amount of information that it can present to you. The command line is where
[26:13.720 --> 26:19.820]  the SigRoc software is very strong compared to Saly. There's also annotations. So with the
[26:19.820 --> 26:23.500]  annotations, you can kind of capture during periods of time. But the thing I want to show
[26:23.500 --> 26:30.000]  you guys the most here is with logic analyzers. It's not specific to Saly, but let's just go ahead
[26:30.000 --> 26:33.420]  and power this guy off. So as you can see on the right-hand side of the screen, the light's now
[26:33.420 --> 26:40.120]  off on the Raspberry Pi. Let's go ahead and power it back on. But also, we're capturing for 30
[26:40.120 --> 26:45.440]  seconds. Let's just stick to four mega samples per second. And then we'll go ahead and power
[26:45.440 --> 26:52.400]  the sucker back on while it starts. So as you can see right here, the only sad panda part about the
[26:52.400 --> 26:57.260]  Saly software is that it doesn't like live view show like the results of what's going on with
[26:57.260 --> 27:02.100]  everything. So you're kind of like, you're kind of stuck with like, just this kind of boring screen
[27:02.100 --> 27:05.720]  here. So you can't really see the sort of interactive like, oh, here's like, you know,
[27:05.720 --> 27:13.880]  the waveforms and whatnot. But whatever, it's all good. We'll go over some, the 2.0 version of it
[27:13.880 --> 27:21.240]  where it does offer some sexy or gooey stuff. So here's the output of our capture. So let's scroll
[27:21.240 --> 27:28.420]  out, and we can see very similar to the pulse view, take this full screen, that there was actually some
[27:28.420 --> 27:34.320]  data captured here, very similar to what we saw earlier. Now, let's scroll in. And as we talked
[27:34.320 --> 27:39.220]  about earlier, remember, channel zero is the TX line of the Raspberry Pi. So of course, we're going to
[27:39.220 --> 27:47.520]  see data. Now, a couple things is that let's say we want to add a protocol debugger, just like what
[27:47.520 --> 27:52.140]  we did with the pulse view. Let's go ahead and add this. We'll say channel zero, the serial, that's
[27:52.140 --> 27:57.680]  the TX channel. And let's click Autobot, right? So let's pretend for a second that we do not even
[27:57.680 --> 28:01.780]  know the baud rate of this device. Let's pretend that we actually think that it's UR, but we
[28:01.780 --> 28:06.460]  actually don't know if it's TX or RX. We've already actually kind of figured out that it's TX, because
[28:06.460 --> 28:11.860]  remember, channel zero, we're seeing data. It's transmitting data to us. RX is a flat line because
[28:11.860 --> 28:17.020]  we're not sending any data back. So we do not know the baud rate. Let's just pretend like we want to
[28:17.020 --> 28:22.500]  open up like a screen session or some type of like a serial session with the device over TTY serial,
[28:22.500 --> 28:28.320]  but we do not know the actual bit rate of that serial connection. So we'll just leave that
[28:28.880 --> 28:33.080]  default, default 9600. We'll click this little checkbox here, Autobot. We'll keep everything
[28:33.080 --> 28:37.840]  else default as well. This is all pretty standard for a normal serial interface on an embedded
[28:37.840 --> 28:45.360]  system. We'll click save. We now see the async serial is here in this corner. And kind of a
[28:45.360 --> 28:52.040]  cool little thing you can do also to help you figure out that baud rate. This is pretty neat.
[28:52.040 --> 28:58.080]  Now earlier, I'm going to bring this up for you guys real quick. In the actual slide presentation,
[28:58.080 --> 29:02.720]  I had this little table here that showed the actual microseconds as well as the baud rate
[29:02.720 --> 29:10.360]  in this table. So if it's 833 microseconds, it's 1200. The bit rate is 1200. If it's 52
[29:10.360 --> 29:18.580]  microseconds, it's 1,900. If it's 8 microseconds, it's 1,500. Now if we go back here, what we can
[29:18.580 --> 29:26.980]  actually do is we see the actual, let's take a look here, the waveform. So from where the actual
[29:28.180 --> 29:35.300]  rising edge to a falling edge of one complete uniform wave. Here we go. It's a good one.
[29:36.640 --> 29:44.820]  It's super tiny, but I hope you guys can see that. 8.5 microseconds. It's pretty nifty because
[29:44.820 --> 29:50.020]  that basically tells us what the baud rate is without us even having to measure the baud rate.
[29:50.020 --> 29:56.960]  So if we go back to our table here, remember 8.5? 8.5 is what it measured as the baud rate.
[29:56.980 --> 30:05.940]  We look here and 8 microseconds is 11,500. Remember, digital is never going to be 100%
[30:05.940 --> 30:09.500]  accurate. It's going to do its best at that representation. Also, there's latency in the
[30:09.500 --> 30:14.420]  cable. There's latency in USB 2.0. In this case, this is one of the cheaper logic analyzers using
[30:14.420 --> 30:19.220]  USB 2.0. So either way, it's not going to be 100% accurate. It's going to be like slightly off,
[30:19.220 --> 30:24.240]  but it's safe to assume that it's closest to that number than it is to any of these other numbers.
[30:24.240 --> 30:29.580]  That being said, let's just do something a little wacky here and just enjoy the
[30:29.580 --> 30:35.900]  luxurious features of the Saley software. I just lowered the sample time to five seconds.
[30:36.140 --> 30:39.620]  Remember, if we go back here to the settings, we have it set. Let's just
[30:40.140 --> 30:44.220]  see it automatically detect. It's already changed, but let's just put it back to 9600.
[30:44.260 --> 30:47.580]  Imagine this is like a fresh scan. We'll power the device off
[30:49.440 --> 30:54.040]  and then we'll power the sucker back on and then we'll go ahead and start sampling.
[30:54.240 --> 31:00.060]  So based off of the sample rate, the Saley software is smart enough to realize what that
[31:00.060 --> 31:05.060]  particular baud rate is. In this case, it already converted to us. Well, that is not the actual
[31:05.060 --> 31:11.620]  bit rate, even though that would probably work. It's 11,500. It's close enough for what we're
[31:11.620 --> 31:18.800]  trying to do here. So let's take it a step further and then let's switch this back over to 30 seconds
[31:21.560 --> 31:28.380]  and let's power it off and then let's power it back on again. Now that we know our baud rate,
[31:28.380 --> 31:36.820]  we'll just see what it can do. Let's make it full screen because you all know what a Raspberry Pi
[31:36.820 --> 31:40.800]  looks like. I can't make it full screen. I'm going to sit here and just stare at this thing and boot
[31:40.800 --> 31:57.470]  up. So while we're having a little break, let me ask you one of the questions. So I have a question
[31:57.470 --> 32:08.270]  here. Is the Saley or the PulseView Logic Analyzer software free and open source? How would you go
[32:08.270 --> 32:14.910]  about downloading or purchasing those? The Saley software, it is actually free.
[32:14.930 --> 32:20.850]  It is not open source, however. It's free. You can download it straight from their website.
[32:21.590 --> 32:26.590]  You can't compile it because, again, it's not open source, but it's 100% free. You don't have
[32:26.590 --> 32:33.450]  to spend a dime for it. However, the Sigrock, so the PulseView software, I believe the GUI is open
[32:33.450 --> 32:38.550]  source. I know the Sigrock CLI is open source because I just compiled it actually like two
[32:38.550 --> 32:47.790]  hours ago. But yeah, so the Saley Logic, free, not open source. Sigrock PulseView, 100% free,
[32:47.790 --> 32:52.870]  maybe open source. Sigrock CLI, free and open source.
[32:54.530 --> 33:01.850]  And taking a peek here real quick, we can see in the decoded protocol section here that we actually
[33:01.850 --> 33:09.630]  have the output of what we saw over the UART interface. So under voltage, it's kind of printed
[33:09.630 --> 33:15.090]  funky here, but that's the actual output of what it's seeing. We had it set to the ASCII,
[33:15.090 --> 33:21.370]  so the output is being displayed in ASCII format. So kind of neat. You can see all that kind of
[33:21.370 --> 33:27.310]  stuff. Scrolling even further down here, we have detected, blah, blah, blah, but go to the very
[33:27.310 --> 33:32.590]  bottom. Maybe we missed it, but it would even capture... Yeah, there we go, like Raspberry
[33:32.590 --> 33:38.950]  Pi login. And that's basically on the UART connection waiting for the typical Pi password,
[33:38.950 --> 33:43.670]  Raspberry, because no one ever changes their default on that. So anyways, as for that
[33:43.670 --> 33:50.370]  particular demonstration, that's pretty much it. And kind of continuing on with that particular
[33:50.370 --> 33:54.610]  question that was asked regarding the free and open source nature, are there any other questions,
[33:54.610 --> 34:01.790]  I guess, up until now? Yeah, I have just one more for you. What is the
[34:01.790 --> 34:07.110]  max number of logic analyzer channels needed for most IoT situations?
[34:07.850 --> 34:15.210]  That's a good question. And I'll be perfectly honest, I rarely run into an instance,
[34:15.210 --> 34:21.310]  I do this, you know, I'm not like hacking on IoT, like full time with my day job. Again,
[34:21.310 --> 34:28.010]  I'm a pin tester. But I do it a lot, just kind of as a hobbyist, as well as just kind of as a
[34:28.550 --> 34:34.190]  side type thing. There's very rare instances that I've run into a situation where I needed more than
[34:34.190 --> 34:40.550]  eight channels. So in cases that I've ever used these logic analyzers, it's mostly been on three
[34:40.550 --> 34:51.710]  different protocols, UART, SPI, and I2C. And none of those three, I guess, protocols really require
[34:51.710 --> 34:56.490]  more than eight channels. Now, I don't want to say it wouldn't be necessary. But I would say that
[34:56.490 --> 35:01.970]  it's kind of a low likelihood that if you're trying to get started as like a hobbyist,
[35:01.970 --> 35:06.390]  that you'll actually need more than eight channels. And all of the devices that we're
[35:06.390 --> 35:12.910]  working with here, support eight channels, you can buy them up to like, shoot, I don't even know,
[35:12.910 --> 35:19.130]  I know, I know Morgan on our team has the big one, I think it's six, is it 16 channels? Is that
[35:19.130 --> 35:28.010]  their biggest? Or is it the 16? Yeah, the big, the big boy. And I don't know that I would like
[35:28.010 --> 35:33.310]  have a need. However, it would be super handy to have in case I ever did have that need.
[35:33.310 --> 35:37.510]  But I would probably err on the side of saying that it's likely that eight
[35:37.510 --> 35:44.760]  channels would be good enough for you. Okay, yeah, no more questions yet.
[35:46.080 --> 35:52.980]  So speaking of which, UART, SPI, and I2C, how do they function? So as we saw earlier,
[35:52.980 --> 35:56.560]  UART is an asynchronous connection. So what that actually means is that there's no
[35:56.560 --> 36:03.080]  clock on either side of the connection, controlling the actual rate that data is being transferred.
[36:03.080 --> 36:09.460]  It's an agreed upon number where you're supposed to actually know. So the bit rate
[36:09.460 --> 36:15.580]  and the baud rate is important for that. How it determines the actual connection speeds also
[36:15.580 --> 36:22.120]  is it uses parity bits. So there's basically another layer of overhead that's being sent
[36:22.120 --> 36:26.960]  over the line of communication so that the negotiation and the actual transfer of data
[36:26.960 --> 36:32.420]  can take place. With SPI and I2C, they're actually synchronous, meaning there is a clock
[36:32.420 --> 36:39.320]  that's determining the communication time. So for instance, SPI operates on a slave master
[36:39.860 --> 36:45.820]  model. So the master is the actual determination of the clock speed. That's the one with the actual
[36:45.820 --> 36:50.840]  crystal that's going to determine how quickly data is going to be sent. The slave is going to
[36:50.840 --> 36:57.040]  basically accept that at that particular rate. And that number is negotiated throughout the process.
[36:57.040 --> 37:05.420]  I2C functions in a very similar way. Moving on to the actual interfaces associated with these
[37:05.420 --> 37:10.940]  three different protocols. Again, UART has two channels. Again, the channels column here is
[37:10.940 --> 37:16.320]  assuming that ground's hooked up. So disregard ground right now. This is only the data lines
[37:16.320 --> 37:20.680]  and the information communication lines that's taken place that we're really concerned with here.
[37:20.680 --> 37:28.040]  That's RX and TX for UART. SPI has four channels. That's going to be MISO, MOSI, CS, and CLOCK.
[37:28.040 --> 37:33.240]  Chip select is enable. And CLOCK is, again, the determination of how quickly that data is going
[37:33.240 --> 37:38.520]  to be sent and received. MISO and MOSI are a little bit interchangeable. It can just depend
[37:38.520 --> 37:43.220]  on the situation that's going on. So with SPI specifically, remember there's master-slave.
[37:43.440 --> 37:49.960]  The master will send out data to the slave over MOSI. That stands for master out, slave in.
[37:49.960 --> 37:57.200]  The master will receive data from the slave over master in, slave out. The master will determine
[37:57.200 --> 38:02.980]  the clock rate. And the chip select is the enable. So the chip select is only applicable whenever
[38:02.980 --> 38:09.420]  there's multiple slaves communicating with a master. And then I2C is pretty simple. It's
[38:09.420 --> 38:16.460]  SDA and SCL. SCL is the communication for the determination of how quickly data is to be sent
[38:16.460 --> 38:22.460]  and received. And SDA is the actual data line. So moving on from that, I guess, are there any
[38:22.460 --> 38:30.200]  questions maybe with regard to SPI, those two protocols, with how they apply maybe to logic
[38:30.200 --> 38:41.480]  analyzers? Maybe not, because I know we just kind of just answered some questions.
[38:41.480 --> 38:47.140]  I'm sorry. I was kind of muted. Currently, we don't have any questions specifically on this,
[38:47.140 --> 38:51.580]  but I do want to encourage people that are in the actual channel as attendees,
[38:51.580 --> 39:00.060]  please think of questions and post them into the Q&A session. Okay, you can move on, Jonathan.
[39:00.440 --> 39:06.540]  Cool. Yeah, I think we had a disabled chat because we had some flattering comments earlier.
[39:06.540 --> 39:12.280]  That was kind of awesome. I think Sam was mentioning it was one of the first issues
[39:12.280 --> 39:17.540]  we ran into with something exciting here. But anyways, okay, so let's move on to the first
[39:17.540 --> 39:24.460]  exercise. Yeah, so let's move on to the first exercise here. Actually, I'm going to skip the
[39:24.460 --> 39:27.980]  first exercise. Let's move on to the second one, because we just looked at UI. Let's look at something
[39:27.980 --> 39:35.340]  fun. Switch it over to SPI. Also, I want to show you the sexiness of this new Salie software as well.
[39:36.880 --> 39:41.680]  And let's bring up the new hotness here. I had actually never... I didn't know that Salie
[39:41.680 --> 39:47.420]  had released this new software. I think it was Morgan. So Morgan's our lab manager here at
[39:47.420 --> 39:52.980]  Salie. It was either he or Daryl that had pointed this one out. But Daryl showed me some freaking sweet new features
[39:52.980 --> 39:57.640]  that basically have to do with this new software. So just to give you the quick
[39:57.640 --> 40:03.280]  rundown here, we still have... I'm sorry for shifting this screen around and stuff. But remember, we still
[40:03.280 --> 40:08.200]  have the old school... not the old school, the cheaper end logic analyzer hooked up. We're about to
[40:08.200 --> 40:12.740]  switch over to Salie though. I want to show you guys some other stuff. So this is the new Salie
[40:13.200 --> 40:18.100]  Logic 2 software. So we're now at 2. And you can change the amount of channels, of course,
[40:18.100 --> 40:22.880]  that are hooked up here. You can change the different protocol analyzers associated
[40:22.880 --> 40:27.300]  with the connections that you're making. There's, of course, timing markers you can set. There's
[40:27.300 --> 40:32.160]  measurements you can take. And this is the dopest part, is that there's an extension. It's like...
[40:32.160 --> 40:36.920]  I don't know if you guys use Burp Suite that much, but this is the extender. The extender
[40:36.920 --> 40:41.860]  to Burp Suite is what the extensions are to Logic 2. It's sick. You can create extensions and just
[40:41.860 --> 40:47.100]  basically allows you to have a lot of plugins and stuff. So let's go ahead and swap this guy out.
[40:47.100 --> 40:53.340]  And we're going to look at a completely different device. So this Raspberry Pi is going bye-bye.
[40:53.440 --> 40:57.820]  I'm going to put it over there. Bunch of pile of other crap I got. And then we're going to switch
[40:57.820 --> 41:04.000]  to the Salie logic analyzer. And then also we're going to look at this particular device here. So
[41:04.000 --> 41:11.440]  I don't know if anyone on the call right now was at the Rapid7 IoT builds last year. If they were,
[41:11.440 --> 41:17.640]  this will probably look super familiar. So a couple of things. As you can see, we have markings
[41:17.640 --> 41:24.540]  for SPI connection. There you see MISO, MOSI, CS, enable, clock, that kind of stuff. There's also
[41:24.540 --> 41:29.220]  some other stuff here. Disregard this. We're actually only going to use ground. This is for,
[41:29.220 --> 41:33.620]  I believe, an ICSP connection. But we're not going to be doing anything with YATML today.
[41:33.620 --> 41:39.520]  We're going to stick directly to the chip, the flash memory chip that we have on here.
[41:39.520 --> 41:44.800]  Now, it's going to be an open book situation, but we're also going to pretend like we don't know the
[41:44.800 --> 41:49.240]  pin out of this, just to kind of make it interesting. We do know it, but I'll show you
[41:49.240 --> 41:53.680]  guys how you can probably make that determination. Because it's so common that, you know, maybe you'll
[41:53.680 --> 41:59.220]  have like a header pins that are soldered onto the actual VIAs, or maybe they're only VIAs,
[41:59.220 --> 42:04.820]  and you have to solder the header pins yourself, and you have no idea what they are. And maybe,
[42:04.820 --> 42:11.160]  for instance, you have a WSAN 8. So, that means WSAN 8, it doesn't have legs. So, the flash memory
[42:11.160 --> 42:15.680]  chip, it's like all the solder points on the bottom, or if it's BGA, those solder points on
[42:15.680 --> 42:19.780]  the bottom, so you can take a multimeter to figure out what the actual pin out is, even if you found
[42:19.780 --> 42:26.180]  the data sheet. So, kind of nifty here. I'll show what that kind of stuff looks like. So, with that
[42:26.180 --> 42:29.140]  being said, let's just flip this sucker up. This is the part I was telling you guys about earlier,
[42:29.140 --> 42:32.660]  where I'm just like, you're going to have a good time watching me do this, because there's actually
[42:32.660 --> 42:37.720]  four cables. This is double the amount of cables as we looked at earlier. And another little pro
[42:37.720 --> 42:43.020]  tip, actually all four of these cables are not required. For doing SPI, particularly if you only
[42:43.020 --> 42:49.920]  have one slave connecting to master, you actually only need to connect master out slave in, and
[42:49.920 --> 42:53.960]  clock in order to facilitate that connection. But just for shits and giggles, let's just connect
[42:53.960 --> 42:59.960]  them all. Also, I'm going to mooch off the ground interface of this ICSP down here, just to have
[42:59.960 --> 43:05.400]  something. So, anyways, very similar to what we saw with the other ones. The mappings of the
[43:05.400 --> 43:09.900]  Salie are here at the bottom. You can kind of see a little blurry, but my camera's not the greatest
[43:09.900 --> 43:16.720]  quality. Sorry, guys. It goes from zero to seven. And then the channels are on the top, the ground's
[43:16.720 --> 43:20.720]  on the bottom. You can kind of see there how they're laid out. So, we're going to just kind of
[43:20.720 --> 43:25.380]  start. I'm going to plug in ground here first. I'm going to put it in on the far end on this side.
[43:25.380 --> 43:30.320]  And then we'll... I'm cheating a little bit. Remember, you're supposed to pretend. But
[43:31.320 --> 43:36.500]  master out slave in, I'm going to make that zero. So, that's red. So, we're going to start red
[43:37.440 --> 43:45.320]  at zero, and kind of work that way. You're kind of picking up what I'm throwing down here. So,
[43:46.280 --> 44:04.200]  red, orange, yellow, green. And we need to plug this biatch in.
[44:09.220 --> 44:17.280]  So, yeah, the Salie uses a micro USB. The other cheaper logic analyzers use the
[44:18.660 --> 44:23.140]  mini USB, as you can see there. So, we'll grab the micro USB, again, hooked up to my computer.
[44:24.660 --> 44:31.000]  Let's plug this biatch in. And you shouldn't see a light. It's totally normal to, like,
[44:31.000 --> 44:36.800]  not see a light at first with this guy. And, yeah. So, let's continue on. So,
[44:36.800 --> 44:42.820]  let's go ahead and shift the screen over to that side. And we should now see... so,
[44:42.820 --> 44:47.280]  one beautiful thing is, I don't know if anyone on the call has dealt with Salie before,
[44:47.280 --> 44:51.480]  but it's kind of a pain in the ass sometimes to deal with a logic analyzer and unplugging
[44:51.480 --> 44:55.900]  it back in because you have to close the software and open it again. Well, Salie 2,
[44:55.900 --> 44:58.940]  I have the software already open, as you can see here at the top. It's now connected,
[44:58.940 --> 45:05.980]  the light's on. So, I think it's totally dope. But, anyways, the Salie
[45:08.260 --> 45:13.980]  software here, going back to the actual device itself, as I'd mentioned earlier, it supports
[45:13.980 --> 45:19.880]  both digital as well as analog. So, as you can see here, here's the digital. So, we want to put
[45:19.880 --> 45:24.660]  in four. We have a total of four channels going on right now. And we'll just go ahead and do
[45:24.660 --> 45:34.060]  analog and digital. We'll capture at 10 megasamples per second. And also, a couple other things. So,
[45:34.060 --> 45:38.580]  there's three different ways of capturing with this particular one. There's looping. So, loop
[45:39.340 --> 45:44.320]  after a predefined amount of time. There's the timer, where it will record for a period of time.
[45:44.320 --> 45:49.220]  And there's a trigger. So, just to kind of demo some stuff, let's go ahead and do a trigger. So,
[45:49.220 --> 45:54.420]  remember zero... actually, let's not trigger. Let's just do timer. Because we're trying to go
[45:54.420 --> 45:59.400]  black box, right? So, let's assume we don't know which particular channel is which. And this is
[45:59.400 --> 46:02.840]  just some blind device that we found online. And we don't know the data sheet. And it's using
[46:02.840 --> 46:07.700]  something like a WSAN. So, we have no idea, like, which pin is which. So, we have all the channels
[46:07.700 --> 46:12.720]  set up. We have the timer set up for three seconds of capture. Go down here. We're going to go ahead
[46:12.720 --> 46:17.460]  and leave the analyzers blank. And we're pretty much ready to start capturing here. So, I'm going
[46:17.460 --> 46:25.400]  grab the old power cable for this guy. And I'm set for three seconds. So, I kind of need to be
[46:25.400 --> 46:34.880]  quick with my trigger finger here. There we go. So, we got full screen. All right. She's plugged
[46:34.880 --> 46:44.520]  in. All right. So, we got it. Let's go ahead and zoom out here. Now, this is the capture that we
[46:44.520 --> 46:49.960]  just got, right? And this is during the boot up process. So, what you see here is zero through
[46:49.960 --> 46:56.620]  three channel. This is all digital. And on the bottom, it did its best at analog. And the analog,
[46:57.960 --> 47:02.640]  it's not the greatest. Like, it's probably pretty accurate. And you can kind of see the comparison
[47:02.640 --> 47:08.320]  between the two. Like, it tried its best at measuring those voltages, but probably didn't
[47:08.320 --> 47:13.500]  quite do the greatest that it could. But either way, there's analog. I just want to show you guys
[47:13.500 --> 47:18.140]  some of the analog. And it's cool to have and stuff like that, but it's not really the purpose
[47:18.140 --> 47:22.820]  of what I'm wanting to show you guys right now. Now, say, for instance, that you don't know
[47:24.160 --> 47:29.720]  the mechanism of... you know that it's SPI, but you don't know which pin's which, right?
[47:29.820 --> 47:36.960]  So, whenever we're looking at this device, remember, the top here is MISO. The bottom's
[47:36.960 --> 47:42.120]  MOSI. Channel zero is master-out-slave-in. As I mentioned earlier, master-out-slave-in
[47:43.160 --> 47:49.560]  is the information that's basically being transmitted from the actual chip to us. And
[47:49.560 --> 47:54.260]  it's probably going to be a little bit spontaneous. There's a lot of opcodes being set. There's a lot
[47:54.260 --> 47:59.180]  of different various settings being aligned with the actual device. And typically, that's one of
[47:59.180 --> 48:04.880]  the first things that'll start communicating, as we can see here. So, we zoom in. And a little bit
[48:04.880 --> 48:09.200]  telltale thing is that we're starting to see some type of communication taking place right here.
[48:09.200 --> 48:16.000]  A little sporadic. We also see right here channel one. Channel one, in this case, is clock.
[48:16.900 --> 48:21.140]  Remember, clock is going to actually set the cadence for how it communicates. 1, 2, 3, 4,
[48:21.140 --> 48:28.640]  5, 6, 7, 8. It's a full actual byte of data. That's pretty telltale. So, right here, of course,
[48:28.640 --> 48:34.300]  channel zero, we have a little bit of some type of sporadic data being actually set. Channel one,
[48:34.300 --> 48:41.760]  we have kind of a constant cadence of information being... of the waveform itself. And then enable,
[48:41.760 --> 48:47.640]  what enable is, say, for instance, there's three slaves communicating with the actual master node.
[48:47.780 --> 48:54.260]  The enable will tell... it'll flip the bit for when that device can communicate or not.
[48:54.280 --> 48:58.320]  So, you'll oftentimes see... it might be a little bit of a mismatch in our timing, which we can also
[48:58.320 --> 49:03.300]  fix. But you'll often see with the enable that, for instance, right here, there's basically like
[49:03.840 --> 49:09.000]  a 1, 1, 1. There's three 1s right here. It's going to kind of encompass that entire
[49:10.220 --> 49:18.920]  section, if that makes sense, or cycle. So, it's pretty easy to tell if you just kind of scan it,
[49:18.920 --> 49:23.840]  as we just did, which one's MOSI, which one's clock, and then which one's going to be enable.
[49:23.840 --> 49:28.260]  Again, enable, in our case, channel two and three is actually not even required.
[49:28.900 --> 49:32.680]  So, taking a little bit of a deeper dive, let's take a look at the actual protocol in that
[49:32.680 --> 49:39.880]  analyzer. We'll click SPI here. Remember, we have MOSI set on zero. We have MISO set on three.
[49:39.880 --> 49:47.160]  We have clock set on one. And we have enable set on two. We'll leave everything else default,
[49:47.160 --> 49:52.680]  and we'll click save. Kind of interesting, because you can actually find more deeper
[49:52.680 --> 49:59.760]  information about the actual device and the settings that it's applying as it's booting up.
[50:00.820 --> 50:10.220]  So, for instance, like right here, this is the actual decoded binary format. If we go here to
[50:10.220 --> 50:14.960]  the settings, we can change whether it's in binary, decimal, hexadecimal ASCII, and then take a look
[50:14.960 --> 50:19.680]  at the actual value. So, in this particular case, it's like one, one, zero, zero, one, zero, one,
[50:19.680 --> 50:24.660]  zero. And that's the actual location where it made the determination. You can see it up here at the
[50:24.660 --> 50:28.720]  top as well, where it's decoded. And what's kind of also interesting with this is you can take it
[50:28.840 --> 50:35.340]  a step further, and you can pull up the data sheet of the device. In this particular case,
[50:35.340 --> 50:43.840]  the model of this is the MRF49XA. It's a... I believe this one was a SOP8. I'm not 100% sure
[50:43.840 --> 50:50.300]  on that, but either way, it's just an RF flash memory chip. So, let's take this code that we got
[50:50.300 --> 50:56.420]  here, one, one, zero, zero, one, zero, one, zero, and let's just copy that. And then let's go back
[50:56.420 --> 51:02.500]  here, and let's just paste that in. So, it's... I already had it pulled up, so I'm kind of cheating
[51:02.500 --> 51:06.960]  right now. So, it's kind of interesting because you can take that, and this is exactly what a
[51:06.960 --> 51:10.860]  developer would do as they're kind of producing these types of devices. They're going to, like,
[51:10.860 --> 51:16.620]  set these codes, and this is going to sort of initiate the actual SPI flash storage of the chip.
[51:16.620 --> 51:23.100]  In this particular case, what we saw was one, one, zero, zero, one, zero, one, zero. Let's paste that
[51:23.100 --> 51:28.600]  in again. That's right here. So, we see the command code bit right there, and then we can see here
[51:28.600 --> 51:36.140]  below that bit seven through four are the first in, first out, fill bit counts. We have bit three. So,
[51:36.140 --> 51:42.020]  in this particular case, what you want to do is the immediate one below it is you match the next
[51:42.020 --> 51:46.080]  three and then map it back over to bit seven through four. In this particular... they don't
[51:46.080 --> 51:51.480]  always map, like, seven, like, in a range like that, but in bit three, for instance, like,
[51:53.220 --> 52:00.100]  this guy is set to zero. Bit three, that basically says synchronous character length bit. It's set
[52:00.100 --> 52:05.980]  to word long. So, I don't want to continue going down this rabbit hole here, but it's something
[52:05.980 --> 52:10.400]  that's kind of cool to when, like, when you're debugging, you can kind of map it back to the
[52:10.400 --> 52:15.140]  data sheet to actually figure out what's going on as far as settings being applied to the chip
[52:15.140 --> 52:19.380]  itself. One other really cool thing I'm going to show everyone here real fast is we're going to
[52:19.380 --> 52:24.900]  make some changes here. I'm going to go back to the actual mapping of the SPI interface.
[52:24.960 --> 52:31.040]  Pretty sweet. I mentioned earlier we don't need MISO and we don't need enable. So, let's select
[52:31.040 --> 52:36.320]  both of those to none. And let's do something else. This is kind of cool. This is actually a
[52:36.320 --> 52:46.200]  plug-in that you can use with this. We're going to select SDMMC from SPI. So, this chip, it's not
[52:46.200 --> 52:55.400]  either an SD nor is it an EMMC chip. It's just flash storage. It's not like an SD actual device
[52:55.400 --> 53:02.040]  nor is it a multimedia controller. But let's just pretend like it is for a second. You select the
[53:02.040 --> 53:11.020]  input to go into this particular plug-in and then we'll click finish. And if it were an SD
[53:11.020 --> 53:16.540]  or if it were an EMMC, it'd be pretty sweet because up here, as you can see where I have
[53:16.540 --> 53:20.500]  kind of hovering over, it'll kind of just show you the actual opcodes and the actual information
[53:20.500 --> 53:25.540]  that it's presenting. It'll kind of interpret that for you. So, just kind of another sweet feature of
[53:26.960 --> 53:34.320]  the logic analyzer software. I just want to kind of show you guys that real quick.
[53:35.860 --> 53:41.580]  And I know we're running kind of low on time. Darrell, are we kind of towards the end right now?
[53:41.720 --> 53:46.180]  No, we got time for some questions. I have a couple questions here before you move on.
[53:46.460 --> 53:53.040]  So, this is kind of stepping back, but do you have to worry about sample rate with
[53:53.040 --> 53:58.980]  cheaper analyzers, like missing data or misalignments and things like that?
[53:59.640 --> 54:08.300]  Yeah, that's a good question. I'll try to answer that with a little demo of what that sample rate
[54:08.300 --> 54:13.920]  actually means for the, like for instance, the Salie logic analyzer, which can have very high
[54:13.920 --> 54:21.600]  sample rates. The quick and dirty, the TLDR I'll give you is that for the protocols that we're
[54:21.600 --> 54:28.880]  looking at here, for the most part, the sample rates that these two cheaper guys support are
[54:28.880 --> 54:34.460]  satisfactory for what we're needing. I mean, it's whenever you're diving into the really quick
[54:34.460 --> 54:41.480]  protocols that it really makes a lot more of a difference. Because a lot of times with the
[54:41.480 --> 54:47.760]  really quick sample rates, like say for instance, let's increase this to... well, I don't know if
[54:47.760 --> 54:56.760]  I'll be able to, because I'll be honest, this logic analyzer can only go up to 50, but like,
[54:56.760 --> 55:04.720]  screw it, let's do it anyway. Another question on there is similar to that same topic. Is there
[55:04.960 --> 55:09.800]  a general rule on what samples per second selection that you actually make when you're
[55:09.800 --> 55:16.200]  setting something up? There's not really a general rule. It's more of a... this is just
[55:16.200 --> 55:20.060]  my own experience. Now, Daryl, you might have your own answer for this, but I would say I
[55:20.060 --> 55:25.440]  typically use it for the default, just depending on what it is. And what I use this for is typically
[55:25.440 --> 55:30.020]  for UART, SPI, and I2C. I would heavily be interested to hear what you have to say.
[55:30.120 --> 55:39.320]  Typically, I'm pretty much the same way. What I will do is if the sample rate's not high enough,
[55:39.320 --> 55:45.860]  I've actually had my Sele start throwing errors and tell me that it was missing data,
[55:45.860 --> 55:52.420]  that it wasn't sampling quick enough. I had that just recently looking on some Dataflow.
[55:52.660 --> 55:59.360]  As soon as I kick it off, it'd throw an error in telling me that it was a missample rate.
[55:59.980 --> 56:08.180]  So, I was able to crank it up until the error went away. So, again, sometimes I'll also just
[56:08.180 --> 56:14.260]  crank it up out of the blue if I know for a fact that it's a high-speed device that's going to be
[56:14.260 --> 56:20.580]  generating a lot of fast traffic. Typically, when you're looking at UART, SPI, and stuff like that,
[56:20.580 --> 56:28.800]  amazingly enough, the speed is often not used as even high as the chip can go. Like UART,
[56:28.800 --> 56:34.340]  I've seen interchip comms on a UART that can literally... the chips are designed to drive at
[56:37.460 --> 56:45.160]  what, over 3 million bits per second across there. But yet, the developers of the device
[56:45.160 --> 56:54.220]  had it set up to communicate at 9600 bulb. That makes sense. Yeah. And I've also found that if
[56:54.220 --> 56:59.180]  you go too high, this particular Sele does not support it. But you also don't want to go too
[56:59.180 --> 57:03.840]  high because if you go too high, this, what you see right here, get out of the screen,
[57:04.320 --> 57:09.500]  it'll just be a giant blob. It's just a mess. It's capturing too much sampling and it's kind
[57:09.500 --> 57:15.500]  of just inaccurate at that point. So, it's a fine line between the two. And another quick point on
[57:15.500 --> 57:21.380]  that also is, typically, the higher the sample rate, the more memory you're going to eat up to.
[57:22.220 --> 57:34.310]  That's a point. Are there any other questions? Not at this time. Cool. And quick question,
[57:34.730 --> 57:38.650]  how much more time do we have here? Just to make sure. I don't want to go too far over time.
[57:39.170 --> 57:43.950]  We've been at it for an hour. So, I think we got at least another 10 or 15 minutes.
[57:44.730 --> 57:49.490]  Definitely. You can definitely go for another 15 minutes. The next talk starts at 8 PM.
[57:49.870 --> 57:55.370]  Perfect. Okay, cool. I wasn't 100% sure on that, but that works out great because we have one more
[57:55.370 --> 58:03.970]  demo as well. So, we've talked about... we did a little kind of a cheater exercise on Raspberry Pi.
[58:04.950 --> 58:12.350]  We did... I showed you guys how to sort of blindly identify SPI as well.
[58:12.850 --> 58:17.290]  And then next, let's switch back over to UR. It's more of a real world example.
[58:18.810 --> 58:22.870]  So, let me go ahead and unplug these guys and plug the power first on this guy here.
[58:24.210 --> 58:29.430]  Let's switch back here. Make sure I don't bust off any of these header pins live on camera
[58:29.430 --> 58:33.030]  because this is Daryl's device and it would suck to break it right in front of him.
[58:33.030 --> 58:40.190]  And let's pull over another device. That's going to be this guy.
[58:40.930 --> 58:46.990]  So, we're going to stick to the theme with the Salee. So, Salee is still going to be used.
[58:47.190 --> 58:51.430]  In this particular case, we're going to check out UR, but using the new Salee 2 software.
[58:51.770 --> 58:59.270]  This particular device, it's a Z-Wave hub, I guess, so to speak. So, it's a hub used in
[58:59.270 --> 59:04.570]  automation. I'm pretty heavy into home automation here at my place and that's something I've always
[59:04.570 --> 59:11.370]  been fascinated with. But this particular device, it's a Z-Wave hub. And let's dig right in.
[59:11.370 --> 59:18.790]  So, right off the bat, something that can easily be noticed, I guess, is that on this device,
[59:18.790 --> 59:27.770]  there was these three header pins. I soldered the headers on, but previously it was just three
[59:27.770 --> 59:35.030]  holes just kind of sitting there. And that's kind of telltale that maybe it might be kind of
[59:35.030 --> 59:40.890]  interesting to kind of poke at. It can be anything. It can be I2C. Maybe there's an EEPROM chip on
[59:40.890 --> 59:46.510]  here that's disclosed or it could be anywhere. It could also not be on here. And when I mentioned
[59:46.510 --> 59:53.990]  WSAN earlier, actually, I can't quite tell if this is WSAN or actually a BGA, but either way,
[59:53.990 --> 01:00:01.010]  same difference. Sometimes you can't actually see the legs of the device to where you map it out
[01:00:01.010 --> 01:00:06.970]  to say, for instance, these headers, but rather sometimes you can, which is what you see right
[01:00:06.970 --> 01:00:15.170]  here. This is a traditional TSOP8. So, TSOP8, it's got the legs. WSAN does not.
[01:00:16.650 --> 01:00:20.890]  And I'm pretty sure it's WSAN. It might be BGA, but I'm pretty confident that it's WSAN. This one
[01:00:20.890 --> 01:00:27.870]  for sure is a BGA microcontroller. But either way, sometimes you can't take a multimeter to check
[01:00:27.870 --> 01:00:33.950]  that this pin right here connects to that pin right there. So, therefore, sometimes a logic
[01:00:33.950 --> 01:00:38.010]  analyzer will come into play. And then that's where it's usually beneficial to do this type
[01:00:38.010 --> 01:00:42.030]  of stuff. So, let's just move on. Let's plug this sucker in and see what we get.
[01:00:50.240 --> 01:00:55.760]  So, we only need a couple of connections here. So, I'm going to borrow the cables that I was
[01:00:55.760 --> 01:01:01.780]  using earlier for the UART. So, in this particular case, there's only three connections being made.
[01:01:02.580 --> 01:01:10.000]  One thing you can do with this is basically take a multimeter to figure out which one's ground.
[01:01:10.000 --> 01:01:13.800]  In that case, let's just assume that I did that because I know which one's ground. But like,
[01:01:13.800 --> 01:01:17.900]  it's pretty easy to tell which one's ground with just a multimeter.
[01:01:18.800 --> 01:01:23.940]  So, and the ground is actually going to be the pin on the far right in this particular case.
[01:01:23.940 --> 01:01:31.880]  So, let's hook up black to ground. And let's just hook up, you know, white and like this silver one
[01:01:31.880 --> 01:01:38.360]  to the other two, not knowing which one's which. So, again, using the handy dandy mappings that
[01:01:38.360 --> 01:01:46.840]  we have on the Stanley, we plug that sucker right in to ground. And then we plug in the other two
[01:01:46.840 --> 01:02:02.930]  to channels zero and one. Kind of easy. And next,
[01:02:02.930 --> 01:02:11.470]  let's, you know what, let's do a trigger. We're kind of gambling right now.
[01:02:12.050 --> 01:02:16.770]  We're supposed to be in Vegas right now. So, again, let's do some type of gambling, right?
[01:02:16.770 --> 01:02:21.270]  We don't know which one's which one's transmit. But what we're betting on right now is that
[01:02:21.270 --> 01:02:26.010]  channel zero is transmit. We have no idea. So, let's just figure out that's what it was. And
[01:02:26.010 --> 01:02:32.090]  what we're triggering on is a rising edge. And what that says is that whenever you see a rising
[01:02:32.090 --> 01:02:37.690]  edge in the transmission, in that waveform, that's when you start capturing. So, in memory,
[01:02:37.690 --> 01:02:41.930]  it's capturing the whole time. But the actual capture that comes back and returns to you
[01:02:41.930 --> 01:02:47.870]  is the actual, the trigger that you set here. You can trigger rising edge, falling edge,
[01:02:47.870 --> 01:02:52.370]  high pulse, or low pulse. In this particular case, let's just say as soon as you see some
[01:02:52.370 --> 01:02:56.850]  type of traffic going on on channel one, that's when we want you to capture. And we want you to
[01:02:56.850 --> 01:03:01.670]  capture for three seconds. Delete everything else afterwards. And we only need two channels here.
[01:03:01.670 --> 01:03:05.450]  So, let's get rid of those other two. We're going to leave it at 50 megasamples per second.
[01:03:05.990 --> 01:03:12.950]  And that is that. We're not going to capture on analog. So, let's... actually,
[01:03:12.950 --> 01:03:17.110]  what we're going to do next is we're going to close out of that. We're going to click start.
[01:03:17.870 --> 01:03:21.670]  It's literally waiting for the trigger. So, you see down there in the bottom right-hand corner,
[01:03:21.670 --> 01:03:30.630]  waiting for trigger. Let's plug this bastard in. Holy shit, we're correct. Yeah. So, we...
[01:03:30.630 --> 01:03:38.850]  well, we still have the stupid... let me delete these... the decoders. This is my bad.
[01:03:40.270 --> 01:03:45.910]  Let me get rid of that. And yeah, if we're in Vegas, we basically... we bet like 100 bucks on
[01:03:45.910 --> 01:03:52.790]  red and it landed on red because it's exactly what happened here. So, go us, right? Channel zero
[01:03:52.790 --> 01:03:58.570]  is TX, just as we were hoping for. So, that trigger was met and it recorded for three seconds. So,
[01:03:58.570 --> 01:04:02.950]  scrolling into here, we can see some of the data. Of course, you know, this is like the zero one,
[01:04:02.950 --> 01:04:09.310]  zero one. And this is the part, as I showed you earlier, with the OG logic analyzer... sorry,
[01:04:09.310 --> 01:04:17.570]  the OG logic software. We'll put input channel. We're set to zero. 11.5200. We don't know what
[01:04:17.570 --> 01:04:22.290]  the baud rate is for this guy. I believe it actually is 11.5200. Remember, we talked about
[01:04:22.290 --> 01:04:27.170]  how to check that. But of course, here we go. We're seeing all the data as well as part of
[01:04:27.170 --> 01:04:36.270]  the boot up. So, boot SPL 2017 and just various other information that it's printing out,
[01:04:36.270 --> 01:04:42.050]  standard out as it's performing the boot sequence. So, anyways, just wanted to show
[01:04:42.050 --> 01:04:48.210]  you guys another example of that on the new software here. It's pretty slick. It's totally
[01:04:48.210 --> 01:04:54.510]  awesome. I like it a lot. You know, it's super useful. You can see like the parity bits. This
[01:04:54.510 --> 01:05:00.250]  is basically the little white dots is kind of managing the communication timing whenever it's
[01:05:00.250 --> 01:05:06.550]  sending data back and forth. In this case, it's transmitting. So, anyways, that being said,
[01:05:06.550 --> 01:05:13.510]  that's kind of the end of the demo here. I just want to give another example of what it means to
[01:05:13.510 --> 01:05:19.850]  communicate or what it looks like to communicate using the new Saly 2 software. Questions?
[01:05:21.710 --> 01:05:26.690]  Yeah, let's go ahead. I think we have some questions. Let me look at this first.
[01:05:28.370 --> 01:05:35.210]  If the Saly software works for any analyzer, what would be the consideration in purchasing
[01:05:35.970 --> 01:05:47.530]  the more expensive offer over a cheaper hardware option shown? So, why would I want to buy a
[01:05:47.530 --> 01:05:56.490]  expensive $600 logic analyzer when I can buy a $24 logic analyzer since I could use the software?
[01:05:57.110 --> 01:06:02.330]  Yeah, that makes sense. So, as we talked about the speeds, I don't want to say they're negligible,
[01:06:02.330 --> 01:06:10.670]  but you do get significantly higher recording speeds with the Saly than you would do with
[01:06:10.670 --> 01:06:18.330]  these cheaper versions as well. Another thing, too, is that the actual accuracy of the protocol
[01:06:18.330 --> 01:06:25.290]  decoding I've noticed is higher with the Saly than it is with either of these other two devices.
[01:06:26.910 --> 01:06:35.350]  That being said, it really just depends on what your needs are. In my opinion, it's pretty good
[01:06:35.350 --> 01:06:41.130]  quality. Like, for instance, I've had a couple of times where I was doing some type of logic,
[01:06:41.130 --> 01:06:48.170]  I was doing basically decoding and actually live capture, and I had a crash with the software with
[01:06:48.170 --> 01:06:53.190]  both of these devices. So, you'll notice that it's a little bit sluggish. It's a little bit
[01:06:53.190 --> 01:06:58.910]  rough around the edges. Again, you kind of get what you pay for. The communication, again,
[01:06:58.910 --> 01:07:05.790]  there's been kind of like lags and hiccups with these two. They get the job done, but I've noticed
[01:07:05.790 --> 01:07:12.670]  that the accuracy for how close of how it captures is a little bit more specific with the Saly.
[01:07:12.710 --> 01:07:17.310]  So, if what you're looking to do is going to require you to know those voltages at more of
[01:07:17.310 --> 01:07:21.690]  an accurate level, then maybe consider the Saly versus these guys. I mean, if you're just doing
[01:07:21.690 --> 01:07:27.810]  some general debugging, things like that, I think these are not a bad choice. That's just my
[01:07:27.810 --> 01:07:32.690]  opinion. Daryl, do you have anything to add to that? Yeah, I think accuracy is probably one of
[01:07:32.690 --> 01:07:40.750]  the bigger things and the ability to process at a higher speed, I think, are the value. And that's
[01:07:40.750 --> 01:07:47.830]  why I went with a higher value product. Because I personally often encounter things that those
[01:07:47.830 --> 01:07:54.410]  would not work on at all, just from the fact that it's higher speed. I often get into more
[01:07:56.050 --> 01:08:02.690]  interchip communication analysis, which is often at a much higher speed than external communication.
[01:08:03.650 --> 01:08:11.230]  Makes sense. The other question here is a good question. Do you need special hardware for JTAG?
[01:08:11.690 --> 01:08:21.150]  Yeah. You know, so if you look here, the capability exists for adding JTAG. Actually,
[01:08:21.150 --> 01:08:24.770]  does it? I don't know if it does on this logic, too, or not. I'm still...
[01:08:24.770 --> 01:08:26.610]  I think it does. I'm not sure.
[01:08:26.610 --> 01:08:33.050]  Yeah, it does. Yeah, it sure does. Now, the question was, is there a specific hardware
[01:08:33.050 --> 01:08:40.250]  needed for JTAG? In this case, if you're trying to, like, identify, you know, what is TMS,
[01:08:40.670 --> 01:08:47.350]  if you're trying to identify with JTAG, what are those debug interfaces? You might have the
[01:08:47.350 --> 01:08:52.230]  capability of doing it with a logic analyzer. Now, at that point, you're kind of... I don't
[01:08:52.230 --> 01:08:57.610]  want to say you're putting a round peg in a square hole, but I don't know if you're necessarily using
[01:08:57.610 --> 01:09:02.710]  the right tool. It has a capability of doing it like this, but you might consider using other
[01:09:02.710 --> 01:09:07.790]  pieces of hardware for doing something like JTAG. Now, like, for JTAG, say, for instance, you don't
[01:09:07.790 --> 01:09:12.510]  know what the pinouts are, and you're trying to identify that. That's where you would use something
[01:09:12.510 --> 01:09:16.910]  like, for me personally, I would go after a multimeter first, and I would try to ring it
[01:09:16.910 --> 01:09:22.230]  out with the MCU. So, I'd try to find the data sheet and use that data sheet to identify where
[01:09:22.230 --> 01:09:28.390]  on the MCU, based off those pins of the MCU, where does that fall out, and use that to identify the
[01:09:28.390 --> 01:09:33.170]  pinouts of the JTAG. If you don't have the data sheet, or maybe you don't know where the MCU is,
[01:09:33.170 --> 01:09:38.810]  or maybe it's a BGA MCU, then you'd maybe use some type of boundary scanner. A great example of that
[01:09:38.810 --> 01:09:44.430]  is the JTAGulator. Another thing that you could kind of use the Salee for is a boundary scanner,
[01:09:44.430 --> 01:09:51.410]  sort of. In that particular instance, it could help you, yes. Now, if you're wanting to do something
[01:09:51.410 --> 01:09:58.250]  like program an MCU, or program the device or upload the device to a flash memory to program
[01:09:58.250 --> 01:10:03.370]  an MCU, then you would need some type of programmer, and that's going to be vendor-specific.
[01:10:03.370 --> 01:10:11.050]  So, say for instance, it's a STM32, you could use something like a ST-Link device. J-Link supports
[01:10:11.050 --> 01:10:16.250]  OpenOCD in a lot of cases, so it can support multi-manufacturers. If it's like an Atmel,
[01:10:16.250 --> 01:10:21.490]  you'll want to use like a Pickett. So, if you're wanting to either dump or flash some firmware onto
[01:10:21.490 --> 01:10:26.150]  an MCU or flash memory, you'd use whatever programmer is assigned to that particular
[01:10:26.150 --> 01:10:33.290]  chipset. Outside that, you can use a logic analyzer for doing some like limited boundary
[01:10:33.290 --> 01:10:38.850]  scanning, but that's kind of not really why it's designed, but the capability exists.
[01:10:40.030 --> 01:10:45.550]  Yep, and on conclusion, there was one comment, there are a couple comments in here I thought
[01:10:45.550 --> 01:10:51.730]  were funny. One was, it would be funny if someone designed a board with a honeypot header that had
[01:10:51.730 --> 01:11:00.950]  50 volts on it. So, Jonathan would hook up his $300 logic analyzer and watch it burst into flames.
[01:11:01.470 --> 01:11:04.810]  Dear God, yeah, that would fry the man bun right off my head.
[01:11:05.830 --> 01:11:12.830]  So, I thought that was a funny comment, which is definitely the level of evil I would expect from
[01:11:13.250 --> 01:11:19.910]  DEF CON, so thank you for that. And then a couple comments saying you did a good job,
[01:11:19.910 --> 01:11:25.850]  so that was pretty good. So, are there any more questions from anyone as we're getting ready to
[01:11:25.850 --> 01:11:32.330]  conclude? Wait, I think there's one more. One was asking more like model numbers on those cheaper
[01:11:32.330 --> 01:11:40.210]  ones. Do you have that information? I think those are so generic in nature. You know what I'm talking
[01:11:40.210 --> 01:11:44.950]  about, the two cheap logic analyzers. Is there any kind of information on there for acquisition? I
[01:11:44.950 --> 01:11:53.710]  think you had a page that actually showed the link or information to the actual Amazon site.
[01:11:53.710 --> 01:12:02.050]  Yeah, let me see here. I'll actually just real quickly do one even better for whoever asked
[01:12:02.050 --> 01:12:09.630]  the question about that. Amazon.com, if you just search logic analyzer. I mean,
[01:12:09.630 --> 01:12:13.030]  one of the ones we're using is like... I think it was the first one in the
[01:12:13.030 --> 01:12:17.750]  list showed up there at the top. Yeah, that's one of them. If you go up to the top, I think the first
[01:12:17.750 --> 01:12:24.410]  one in the list was one of them we purchased right there. That's one of them. That's the I let go USB
[01:12:24.410 --> 01:12:31.650]  one. I actually have the other one too. It's kind of funny because it came with the
[01:12:31.650 --> 01:12:40.850]  Edify toolkit or whatever. It's got like a red face to it. You may have called any number of
[01:12:40.850 --> 01:12:49.030]  different names. Oh, it's SparkFun. Yeah, SparkFun. Yeah, SparkFun relabels that Chinese one.
[01:12:49.910 --> 01:12:56.130]  Yeah, it's this one. So I mean, just go online really. It's kind of like here's one of them
[01:12:56.130 --> 01:13:02.530]  and here's the other. And it's just you just Google or not Google Amazon search those two.
[01:13:02.830 --> 01:13:09.570]  I'm pretty sure this is exactly both of them. Yeah, perfect. Thanks a lot. Let's see
[01:13:10.230 --> 01:13:18.610]  any more questions. Are hand tech any good? Have you messed with a hand tech before?
[01:13:18.830 --> 01:13:24.990]  I'm not too sure. Hand tech logic.
[01:13:31.250 --> 01:13:37.350]  Oh, oscilloscope or the logic analyzer? Probably logic analyzer since this is a logic analyzer.
[01:13:37.350 --> 01:13:42.810]  I have not. Well, you were there a minute ago before you checked on the
[01:13:43.410 --> 01:13:51.130]  oscilloscope. There was one showing up there as a logic analyzer. I'm sure. And then EK, TEK.
[01:13:53.270 --> 01:13:55.510]  Because we're quickly running out of time here, but...
[01:13:57.950 --> 01:14:00.190]  Oh, I've seen pictures of these guys.
[01:14:02.970 --> 01:14:06.470]  It looks... I mean, it's got two gigs of DDR2 memory. I mean,
[01:14:07.490 --> 01:14:11.330]  it's hella better than I think what any of the Salies have. So,
[01:14:11.730 --> 01:14:15.350]  they're quick and dirty real quick. But that one, that's a very high sample rate,
[01:14:15.350 --> 01:14:18.190]  and that's a lot of memory. So, higher the memory, the higher the sample rate,
[01:14:18.190 --> 01:14:22.970]  the longer you can capture, and the more pinpoint accuracy you can get in those captures.
[01:14:23.790 --> 01:14:27.670]  That's probably, I guess, my two cents on that particular one. And it looks cool. Looks dope as
[01:14:27.670 --> 01:14:35.990]  hell. Yeah, I haven't messed with one, so... Okay, I think that pretty much concludes it.
[01:14:35.990 --> 01:14:40.550]  Hopefully, the people that wanted to ask questions were able to ask questions.
[01:14:40.930 --> 01:14:50.470]  Feel free to reach out to any one of us. Jonathan, you can reach out to him anytime.
[01:14:50.470 --> 01:14:56.070]  He's available. I think he's on Twitter. Do you get your Twitter ID out there, man?
[01:14:56.430 --> 01:15:01.050]  Yeah, Twitter ID, frankensteiner. There you go. Good luck remembering that.
[01:15:01.050 --> 01:15:07.950]  So, if you ever want to ask him any questions or harassing, there you go.
[01:15:08.670 --> 01:15:12.990]  Yeah, if you want to figure out what my address is, I'll honestly just give it to you,
[01:15:12.990 --> 01:15:17.190]  if you're really that curious. You don't have to do whatever, Google it or whatever,
[01:15:17.190 --> 01:15:22.130]  like the person did at the beginning. Well, hey, thank you so much. I think
[01:15:22.130 --> 01:15:26.950]  there might be a few extra questions. So, if either of you have time to jump into the
[01:15:26.950 --> 01:15:33.310]  IOTV Talk, Questions, Text Discord channel, there's definitely people that were pretty
[01:15:33.310 --> 01:15:39.190]  engaged with this talk. Despite the technical difficulties, this was our first and only live
[01:15:39.190 --> 01:15:47.210]  presentation that had any issues. So, I mean, what are the chances of that? It's like getting a bird
[01:15:47.210 --> 01:15:52.630]  pooping on your head. Maybe it's good luck. Nice. It is good luck.