• Author Author: colporteur
  • Date Created: Date Created
  • Views 925 views
  • Likes 4 likes
  • Comments 4 comments
Related
Recommended

RoadTest Support: ACCESS:bit for micro:bit Troubleshooting

colporteur

This is the forth instalment in a series of blog posts to support a RoadTest Review of the ACCESS:bit for micro:bit . The review is being conducted by a student from a high school computer club. Details on how the RoadTest is being conducted can be found here RoadTest Support: ACCESS:bit for micro:bit The Application

 

The objective for this week was to program the ACCESS:bit and have the barrier move. The student was not successful in achieving that objective. The barrier does not move when code is run.

 

It was noted in theRoadTest Support: ACCESS:bit for micro:bit Initial Impressions that the documentation provided from the ACCESS:bit RoadTest Review didn't reflect the device delivered. It was also discovered the code provided in the documentation is not the code currently supported from the GitHub resource link provided.

image

Difference in physical hardware (note: left and right servo not supported & speaker mounting changed)

 

image

Difference in code blocks available for programming. Blocks on left are not available.

 

The confusion created by the poor documentation contributed to the student not getting the ACCESS:bit working. The instructions for what the student needed to do to move the ACCESS:Bit barrier were not clear. It was encouraging to see the student started to troubleshoot the issue without the need for guidance.


At a regular scheduled Google Hangout meeting with the Coach the following was reviewed.

  • Assembly confirmed.
  • Servo physical connection pin out confirmed. (servo can be connected backwards, no keying to prevent this)
  • Servo confirmed working on Arduino. (servo test circuit on Arduino confirm servo operation)
  • Reviewed how the Micro:bit is programmed. (Action item: Need more documentation)
  • Confirm coding practice correct: Successfully ran program to have ACCESS:bit buzzer sound.
  • Install ACCESS:bit batteries and test operation (Action item: install battery & test)
  • Test Servo on Micro:bit directly. (Action item: direct connect servo and test)

 

Using the resources of makecode.microbit.org and the ACCESS:bit resources provided through GitHub, a schematic (left) of the servo circuit is displayed when the code is saved.

image

The schematic is being used as a troubleshooting aid. It doesn't appear to represent the actual configuration of the device. The schematic (left)doesn't show a battery or a switch that are on the ACCESS:bit (right). The device also has a integrated circuit labeled Reg1. The assumption is the battery, switch and circuit are used to operate the servo. The schematic (left) suggests servo motor can be tested without the ACCESS:bit. The focus is to get the device working. Testing the servo without the ACCESS:bit connected is a follow-up test after trying the unit with batteries.

 

The student demonstrated how the micro:bit was programmed. There was some difficultly in explaining how they developed the knowledge learning curve. The documentation to complete the task is not clear. The student has been tasked with documenting, How they uncovered the resources they needed in order to program the device.

 

The student will continue to work independently from the Coach to complete the task of getting the ACCESS:bit working, along with documenting their learning. A Milestone meeting has been schedule to provide the student time to work the problem but also the break point to give assistance in order to avoid struggling.

  • in reply to kmikemoo

    It sounds like we had similar training background. I was a civilian electronic technologist at an airport attached to a Canadian Forces Base. The individuals I worked with, for the majority had their training in the military. I was a college graduate. The station was government run and used a lot of military processes. I mastered documentation working at that site. Accurate logbook entries, scheduled maintenance reports and paperwork up the wazoo.

     

    Most of the scheduled work followed a process. Process, process and more process. My greatest lesson was half split method of troubleshooting. Understanding the whole system, knowing how end to end worked was critical to effectively isolating faults. Starting at one end and working your way through took way to long. Look at the whole system pick a point in the middle and confirm if you go left or right to find the fault.

     

    My memorable do over was setting the receive audio level from AM radio receivers to air traffic control 3db higher than normal. I was doing regular maintenance on the communication system and found an amplifier out by 3db. The amplifier was fine, I failed to set the termination on the audio meter correctly. Bridged instead of 600ohm will do that to you:) I adjusted close to 30 amps before someone came to tell me air traffic control was complaining about audio levels. The senior tech suggested after the third amplifier adjustment something should have twigged.

     

    Lesson learned. If you have 30 identical circuits all working and you start adjusting them all by the same amount. Maybe, just maybe, your setup is wrong. Comparison testing keeps me grounded and not chasing  my tail.

  • in reply to colporteur

    I think what you're doing is great.  As you have shared, how you solve the problem is more important than the solution itself.  As a young man, I would have scoffed at that comment.  After fixing things in the field, I quickly learned to value the process I was taught. When I taught at the US Army Corps of Engineers Prime Power School, you got no credit for an answer that didn't have any supporting work.  You got "0 - PFMN":  No credit - Pure "Fictitious" Magic Number.  You could have the answer wrong but still get passing credit; -1/4  FFE.  75% credit - Fat Finger Error.   Why?  Because the process is that important.  An answer only solves one problem.  A process solves... most of them. image

    See Troubleshooting Mantra #3.

     

    I still get laughed at for breaking out the colored pencils, but they get the job done.  And I always go back to the Given/Find format I learned when I went through the Prime Power School.  What do I know?  Not what do I think I know, but what do I know?  These are the Givens.  See Troubleshooting Mantra #1 & #2.  What do I want to know - in the end?  This is the Find.  It helps keep me on the right path.

     

    Finally, for your students, I also go back to Goezintas (Goes In To's) and Goezoutas (Goes Out Of's).  No goezintas = No goesoutas.  Have you verified your goesintas?  You can't have goesoutas without goesintas.  I've seen expensive controllers replaced for a flat battery.  Guess what?  It didn't fix the problem.  Changing the battery did.

    This is also GIGO - Garbage In = Garbage Out.  Which ever one sticks in the mind of the student / technician / Engineer.

  • in reply to kmikemoo

    Thanks for the commentary M2 .  I have been taking a hands-off approach on the work being done  for the review. I meet (Google Hangout) regularly with the student to discuss progress and set next goals. At the meeting I gather the content for the next blog post and discuss my approach. The student is asked to review the post to ensure the information I am providing is accurate.

     

    I will encourage the student to read your commentary. Entrenching those go-to-first troubleshooting skills are so important. When I made my living at troubleshooting my documentation (i.e. block diagram) was my starting point. The document with its different colour pencil markings looked like a Picaso painting. Nothing like notes on a drawing to help you narrow down an issue.

     

    I developed a similar list to yours for the students in Computer Club. After assembling a computer, if the student came to me with the suggestion, it doesn't work, my first response was what do you mean doesn't work. What have you done to determine what is working and what is not working? A teacher commented one time about me not providing an answer but rather a process to determine the answer.

     

    Our club had a collection of donated desktop computers that student would tear down and assemble. Then we added networking and started working on operating systems before the pandemic.

  • This is actually a great opportunity - although it never feels like it in the moment.  I feel that part of being a good troubleshooter is to be slightly skeptical about the accuracy of the documentation.  I love the task of writing the documentation.  It's not as easy as one thinks.

     

    Why be slightly skeptical about the documentation?  The documentation could be old and outdated.  The product could have changed from design to implementation - and the documentation was written from the design specifications and not updated.  I feel this is exactly what your servo schematic is showing.  Schematically, these are the same circuit (less the switch).  In reality... not so much from a power draw perspective.  Finally, there is the interpretation of what is written.  We have all read instruction manuals that make no sense to us or we think we understand but it winds up being exactly opposite of what we read.  "Trust but verify."

     

    When speaking to customers about a troublesome piece of equipment, I ask the question "What is it doing that it's not supposed to or what is it not doing that it is supposed to do?"  During actual troubleshooting, I ask "What should it be doing?"  "What does it need to have to be able to do that?"  "Am I looking at a symptom or the actual cause?"  The most common cause of an emergency generator failing to start is a flat battery.  No power for the controller to do anything.  I have had customer change the controller and wonder if they got a bad replacement controller.

     

    Troubleshooting Mantra:

    1.  Never overlook the easy.                                                Check battery, fuses (with a meter), fuel level, plugged in, etc.

    2.  If you haven't checked it, it hasn't been checked.          I don't care if you just watched me check it.  You check it.  Trust no one's readings here.

    3.  Have a process and follow it.                                         Start at the power source and trace it through the system.  Or... Start at the end and see where the power finally appears.  Or... divide the circuit in two.  Is it okay up to this point?  Then divide again.  Pick a method and use it consistently.  The times I have hated me the most were when I shortcutted my process and started gun-slinging.

     

    This was written with the student in mind.  Hopefully, they find some helpful tidbits in it.