Posts Tagged ‘Electronics and computer engineering’

ChatBot: Cost Cutting at the cost of User Experience

In Design Methodologies, Education, Embedded Systems, Science & Technology Promotion and Public Policy on August 31, 2016 at 4:09 PM

Many of you may be familiar with chatbots. For those who aren’t, a chatbot is a computer program designed to have conversation with a human being (wikipedia). So, instead of talking to a real person, you talk to a computer program. The chatbot responds using artificial intelligence methods which can also include using databases. For instance, you can ask a chatbot on a merchant website to show you “shoes of size 5, blue in color, for sports and within 50 dollars”. You don’t have to search using a filter and set various thresholds. The chatbot will process your “textual/verbal (assuming there is speech recognition) input” and get you the results.

This technology is being promoted as the next major innovation to improve efficiency. The problem is that “efficiency” is itself a much abused term: I will go into the details some other time. Companies are being told that by using chatbots they can increase customer satisfaction, reduce manpower, automate customer interaction etc. This to me appears far-fetched conclusions. Human beings like to chat with human beings. That is one reason why Honda’s humanoid robot ASIMO and other similar attempts have failed to make a cut as care takers. They simply can’t replace nurses as of today. Artificial intelligence and care taker robots are too hyped as of now.

I agree that in certain circumstances where a conversation revolves around very structured data and can be very specific, chatbots may be useful. However, if we examine how humans search for something, we will find plenty of randomness in that. Most of the music videos that I have liked, I have bumped into them accidentally. This may not be the case with music aficionados but it is with me and others like me who explore certain things randomly and out of curiosity.

The reason I am writing this post is because I had a recent experience with a chatbot which was contrary to the selling point of chatbot providers or those who buy chatbot technology to improve customer engagement. Read the hilarious conversation below. Let me call the chatbot CB though it actually had a name on the service provider’s website.

Me: I wanted to know something.

CB: I am here to help (This is actually a standard beginning response by CB to every conversation that is started)

Me: I wanted to know how I can register for user authentication.

CB: I have found the following links that may be helpful: link-1, link-2     ( a sequence of hyperlinks)

Me (the hyperlinks were not helpful as I had already seen them under the FAQ): The website says that I will be auto-registered for authentication by March 2016. But this is August 2016. How will I be auto-registered now? What should I do?

CB: I have found the following links that may be helpful: link-1, link-2     ( a sequence of hyperlinks; the exact same answer as earlier)

Clearly, CB had no idea what I was talking about. The service provider had initiated some ad-hoc measures for some time to register users for authentication but had not updated whatever provided data to CB. The service provider had also failed to address the discrepancy in time. I understand that business requirements can lead to such temporary measures but it also means that the client support system must be accordingly updated. Otherwise, it makes little sense.  Apparently, CB also had no mechanism to learn about new business measures on its own either. Needless to say that I was not satisfied with the service. This example demonstrated to me not only some of the limits of chatbot technology but also the carelessness with which businesses go about buying and integrating chatbot technology thinking that it is a good alternative to manpower based customer interaction in order to cut cost and increase customer engagement. On the contrary, approaches like this result in customer dissatisfaction and duplication of work and efforts somewhere else. And this experience was with a well known service provider of citizen services!

Component Problems with Electronic Systems

In Education, Embedded Systems, Engineering Principles on December 30, 2014 at 9:37 PM

It is not surprising to find component problems with electronic systems. I was working with a Zedboard recently and it would just not boot from the supplied SD card. The serial driver was properly installed but the LED would not light up. The host PC’s operating system did not complain about any driver issues. Some members on the Zedboard forum complained about the micro-USB socket problem on the board. In any case, when working with a development or an evaluation board, it can become difficult to diagnose such issues. I tried different SD cards as well but to no use.  My laptop can recognize the SD card but Windows is unable to format it!

This experience makes me feel that it is relatively easier to simulate a design and test it for functional correctness. It is more frustrating when components on a board stop working and you do not know which one. For my case, the SD card could be corrupt, the SD card reader could be corrupt; according to forums, there may be issues with the serial port driver etc. It is not that it is difficult to diagnose the issue. It is just that you have try to isolate the problem by looking at different possible issues one by one. It wastes a lot of time especially when you expect a dev/eval board to be up and running quickly.

One board can take away so much time. Imagine if you have to do this for 20 such boards which is usually the case when such boards are procured for student laboratory exercises! Can’t there be a better way to know the status of components? Perhaps it is time to investigate this!

Learning Through Examples

In Education, Embedded Systems on October 24, 2014 at 6:08 PM

I am a big supporter of the “learning through examples” paradigm. Not only it makes the concept clearer, it also leaves an impression in a learner’s mind about the method and the tools used. Over the past couple of months, I have been preparing course slides for an undergraduate course in reconfigurable computing. I have also been preparing laboratory exercises for the students enrolled in the course. I have found it a lot easier to explain important concepts and tool flows using examples. Students have found it to be better than slides which have very few examples or are very abstract (leaving the instructor to fill in a lot of details orally during the lecture).

A good friend of mine, Adam Taylor, has been writing a series of blog for Xilinx’s Xcell publication. The blogs have focused on using the Zynq platform from Xilinx. Zynq programmable SoC combined the strengths of an ARM processor with programmable logic. In fact it has two ARM processors coupled with programmable FPGA fabric. His blog has covered in detail how to use the MicroZed board which features a Zynq SoC. Complete with screen-shots and step by step instruction, those articles will be useful to anyone interested in trying out this new kind of FPGA. Those articles are now also available in a single PDF document for easy reference. The document can be downloaded here.

Embedded system design using both a FPGA and a processor is a complex exercise and any tutorial that makes the concepts and the tool flow easier to understand is always helpful for engineers.

What is the purpose of a lab?

In Education, Embedded Systems on July 22, 2014 at 9:22 PM

Laboratory sessions at universities form an integral part of curriculum. This is specially the case with science and engineering disciplines. While different disciplines have different requirements regarding what will actually be done in these sessions, a basic question to ask is – what is their purpose? I will discuss with respect to labs for computer engineering curriculum. These lab sessions are meant to give hands on experience to students in working with devices like micro-controllers, microprocessors, field programmable gate arrays (FPGA) etc. Often times, students are given codes (programs in a programming language) written by a teaching assistant (TA) which they are expected to use to program the device. They are expected to program the device using some Integrated Development Environment (IDE). The students may be required to modify these programs based on the lab exercises.

Among other things to learn, I have realized that there is too much emphasis on learning how to use the IDEs. This is not peculiar to one country or university. It seems to be the norm at many places if you look at the lab descriptions available online. It is true that different IDEs look dissimilar (obviously!) and the options that they provide to a user can be in different parts of the graphical user interface (GUI) and under different menus. However, they all follow a basic flow which is essential and relevant to the system or device that they target. Good IDEs are similar in layout and are easy to navigate. Therefore, it should be easier for students to move from one IDE to another after they have learned at least one properly. Besides, it is not so much the IDEs themselves but the different steps in the flow which are more essential to learn. After all, IDEs package different steps, necessary to program such systems and devices, into one nice coherent click-and-run flow.

I believe that lab sessions are meant to complement lecture based learning. How the different steps , algorithms, methods etc. taught in a class come together in a coherent manner in order to enable the programming of such systems, is an important learning outcome. Besides, when working with development boards and evaluation kits, students can learn to navigate through user guides, reference designs, schematics, bill of materials (BOM) files etc. These will seldom be taught in class room, but they form a very important part of an engineer’s life in industry. Lab sessions provide an opportunity for students to relate and expand their class room based learning to what actually goes into designing, building and testing real world systems. I think that should be one of the most important guiding factor for faculty members when designing lab sessions.

The Unlikely Places for Electronics Hardware Work

In Embedded Systems, Science & Technology Promotion and Public Policy on June 28, 2014 at 11:27 PM

The world is always changing and big data is changing it in even newer ways. Till a few years ago, no one would have thought that data crunching companies and software companies would get involved in electronics hardware design work. However, that is the case today. Microsoft is building programmable chips and hardware to speed up its Bing search engine (see here  and here). Amazon just released its own smartphone (see here). Companies like Google and Facebook which would typically use custom off the shelf hardware to build their datacenters are now getting involved with real hardware design in order to make their datacenter more power efficient and increase their performance (see here and here). If one were to look at the career openings in these companies, one can find openings for people with electronics or computer hardware design.

On the other hand, if one were to look at companies like IBM, Cisco, Oracle etc. the number of openings in these areas are comparable to those at Google etc. It is no surprise that some industry watchers have begun to wonder if IBM is trying to become Google and Google trying to become IBM. There was a time when IBM did tremendous amount of computer hardware related work, but that is not the case today. A lot of its activities involve work with software.

While companies like Marvell, ST Microelectronics, Infineon etc. continue to work in the hardware domain and supply parts to different players in the electronics ecosystem, companies like Amazon etc. have emerged as the dark horses in this space. They may not be as diverse as Infineon etc. but they are very focused on what they want to do and what they want to offer. Their direction of work is very customer oriented and involves product design which many people like to get involved with.

When Facebook asked Buddha to be Tagged

In Education, Embedded Systems on May 25, 2014 at 8:26 PM

Facebook has this face recognition feature. It automatically recognizes faces in uploaded pics and then provided the option to tag the faces that its software has managed to recognize in those images. It is very successful most of the time. Face recognition is a very active field of research with many groups working on it. It is now part of security systems, the simplest example being laptops that have facial recognition feature for unlocking.

 Now, take a look at the image below. It shows two statues of Buddha at the 10,000 Buddha temple in Hong Kong.

Buddha Statues at 10,000 Buddha Temple, Hong Kong


When it was uploaded to FB, the software identified the two faces in this photograph and asked for tags! It was quite a surprise for me and it made me realize a limitation with existing facial recognition technology. Existing technology cannot differentiate between real human faces or faces which are part of a “non-human” element. This is one reason why facial recognition technology is known to be fooled using images. One can login to a system by showing an image of the person with authorized access. This was discussed by USA Today here. This is also the reason why high security establishments may go for multi-modal authorization in which facial recognition is just one part.

I guess for facial recognition technology to be truly a single point solution for authorization, it will have to learn to distinguish between human and non-human elements. The road ahead has a lot of interesting challenges!

Do you read User Guides?

In Design Methodologies, Education, Embedded Systems, Engineering Principles, Research and Development on May 14, 2014 at 6:32 PM

I am a member of LinkedIn and like many of you am also a member of quite a few LinkedIn groups. The good thing about LinkedIn groups is that the discussions remain professional in tone and content. This is why I like them compared to discussions on other social media platforms where they can vary in tone and content from the most professional to the most ridiculous. In a discussion on such a LinkedIn forum meant for engineers, someone admitted that very few engineers or users of tech tools read the user guides. This is not far from reality. I have seen this when I interacted with practicing engineers on a more regular basis than now. I also see it in academic life.

Personally, I find user guides of development boards, software and hardware tools extremely useful. Reading them once gives me enough confidence in extracting the best out of these tools. For instance, user guides of FPGA vendor providers are very helpful and I am more confident about my design after having referred to the user guide at least once though often these guides can be voluminous. I guess the verbosity of these guides is one main reason why people don’t feel like reading them. The other reason, I think, is the propensity of many practicing engineers, graduate students and others to get  their hands dirty as soon as possible. They want to write code, design a circuit, run simulations etc. without getting bored reading these guides. While this enthusiasm to start working is worth appreciation, ignoring the “reading” part leads to problems later on in the product development process, research methods and has the potential to creep into the results. Basically, this haste leaves one vulnerable to questioning at a later stage. Sometimes this can prove very costly as well especially if it is related to product development. Of course one can always talk about pressure for results from managers, supervisors, customers etc.; this is not a very good excuse. Good managers etc. also understand the importance of being abreast with background information.

Is this issue observed more in the engineering industry than say banking or insurance sectors or for that matter safety critical engineering domains? Perhaps. Engineers take great pride in fixing things. They can use patches for software, make new releases, change components or simply replace the product.  However, bankers and insurers cannot do much once money is gone. The fear of losing money is too great to sustain the dislike for reading guides, whitepapers etc. Similarly those involved with safety critical engineering domains are more mindful about liability issues that aversion to poring over thick user guides is probably a non-issue.

One can also argue that  the presentation style of many user guides is quite boring. I agree when you compare with things that provide “instant thrill” thus leading to a desire to know more. User guides do not provide that thrill but writing code, experimenting with a development board etc. does give a lot of thrill to many engineers. Nevertheless, when it comes to getting a job done properly, there is no other choice but to sweat it out! 🙂

Communication Skills for User Interaction

In Design Methodologies, Engineering Principles, Research and Development on April 12, 2014 at 9:06 PM

I recently used the IVR (Interactive Voice Response) system of an organization tasked with issuing identity cards to citizens. An IVR system is supposed to improve customer experience besides helping the organization in managing complaints,requests etc. Therefore,it plays a very important role. An IVR system comprises one or multiple menus which are read out to a caller who then has to select one of the options. Interestingly, sometimes there are just so many options that one just loses tracks. It also happens when the “menu items” do not sound similar to what the called user has in mind. So what do you do? You just navigate to the one that sounds closest  to what you had in mind and hope that it will solve your problem or you wait for the option to talk to a staff on the other side!

The IVR system that I referred to earlier had peculiar issues. If you selected the option that said something similar to “I would like to know if I need to reapply”, you would expect it to prompt you to give some information based on which you would be told “whether or not” you should reapply. However, this IVR system would give the response similar to “Please do not reapply as it is not desirable to have two identity numbers”. Now how on earth is that helpful?

The IVR system of a prominent smartphone company would give some even more hilarious responses. When you call the number hoping to find a relevant menu or speak to someone, it would tell you something similar to “Please visit our website to resolve your issue”. Now imagine that for some reason you do not have access to internet, then is that response of any help? Absolutely not.

This begs the question about the people (engineers, manager, UI guys etc.) involved in designing IVR systems. Do they really understand how people use a language to communicate? Do they spend some time understanding the common phrases that people use to refer to their issues and then distill a subset that they can use in their system? Do they spend time brainstorming proper responses to different kinds of questions? A good IVR system is not just a software development exercise. It involves understanding about communication and is affected by the communication skills of the team doing the design. Similarly, an IVR system with multiple menus and sub-menus can get difficult to navigate especially for old people. Does the design team understand who the end users are and what kind of communication skills they have? I think these are important questions that should be considered. An IVR system is supposed to provide an easy solution to a user. It should be simple, straight and elegant.

Frustrated with Passwords?

In Embedded Systems, Engineering Principles, Industrial Consortia on January 30, 2014 at 11:21 PM

There is a huge amount of research literature on security, privacy, hacking etc. associated with computer networks of all kinds. Almost all of these networks work on the principle of authenticating users before granting access.  Similarly, all internet based services like your email account, online banking account , Facebook etc. authenticate users before granting access. You need a user id and a password to access all these services. When you use multiple services, you need to create multiple user ids as well as passwords. The problem is that you need to be able to recall these when the need arises. So either you memorize them or write them down somewhere or store in the cloud. This indeed becomes frustrating when you try to use really strong passwords for your accounts. Can there be a better solution that using passwords? Can the sign-in process be simplified? People are making efforts in this direction. There is a an online petition against passwords movement that seeks to educate both users as well as companies to simplify the sign-in process to access services. There are industrial efforts also in this direction. The Fast Identity Online Alliance (FIDO) is also working in the same direction. However, this is not the end of this issue.  Solutions like using device authentication for online authentication restricts the ease of access with respect to devices. For instance, currently you can login to your Gmail account from any computer. However, if a solution ties this login to your personal laptop, you will not be able login through any other device. It remains to be seen how this story unfolds. Will there be really a solution or will users have to live with a compromise between security and privacy concerns on one end and ease of access on the other?

A Tale of Two Samsung Galaxy S4s

In Design Methodologies, Education, Embedded Systems, Engineering Principles on May 14, 2013 at 7:23 PM

When you are in school or college, you are taught about the best ways to do things. It is generally about a point solution. Alternatives are rarely discussed in detail. One almost always looks for the best answer, the best method, the best algorithm. When you begin to work  for a company, you almost always realize that the best solution is not what one is always looking for. Time and market pressures play a role in choosing solutions. You can choose a solution that suits the “taste of the target market“. When you serve more than one market, then it becomes interesting. Would you want to choose two different solutions for two different markets for the same product? This is one of the reasons that analysts cite regarding what Samsung has done with its Galaxy S4 smart phone. While the US and the Korean versions appear identical on the outside, they use quite a number of different components. Their processors, wireless and image processing architectures are different. Supposedly, the Korean version is faster and has a longer battery life because it uses  Samsung’s Octacore Exynos 5 processor which has an architecture (read here) that helps to attain a balance of power efficient and performance more than the Qualcomm Snapdragon processor in the US version. iSuppli’s IHS Teardown Service reveals all the component level differences between the two designs here.

A more plausible reason for the difference in the two architectures is the fact that the LTE bands supported by mobile operators in US and Korea are different (see here). The two processors (essentially system on chips in this case) may not support both the LTE bands. However, it does illustrate an important point related to engineering product design. It shows that you can design the same product with different architectures. While not related to S4, this analysis reminds me of regulations in certain countries which make it compulsory for a manufacturer to source components from local suppliers for products to be sold in the local market.  An example is here. Therefore, as a manufacturer you can end up with different components in different markets for the same product.

I used to think that a consumer electronic item sold in different countries used the same components. That myth now stands broken! While you can easily spot the differences in software, prominent being the language used in user interface, it is not easy to spot differences in hardware.