Saturday 29 December 2018

Orb Retro Gaming Console - What's inside?





Orb Gaming System



The Orb Video Game System is a retro games console which is based on the Nintendo Family Computer, or "FAMICON" as it's more commonly referred to.

A quick look inside reveals, well - not that much actually!   there are 3 pcb's, one has the power socket and s-video adapters on it (top-most),  the center pcb has what must be main system on chip, which is under the black blob;  the bottom pcb has the console on /off and reset switches.



Orb Gaming System PCB



Moving on to the cartridge provided with the console which has the 400 games on..






The top-side pcb contains a single AS7C31025 which is 128K x 8 bit CMOS SRAM chip;  and then a chip blob;  I can only guess there is some sort of micro-controller of sorts under the blob which controls the game selection, so once a game is selected (i.e 1-400 ) from the initial boot-up menu, the cart controller will then grab the selected game from the Flash memory and then push that into the SRAM ready to be loaded up by the main system.





The reverse of the cart pcb showing the single S29GL512,  3v,  512 Mbit Flash Memory.





I picked this system up in an Xmas sale for £15,  but despite the really crappy cheap looking case etc, it is really quite enjoyable and probably very hackable!



Saturday 13 October 2018

Solartron 7150 - Overload Issue

I already have a working one of these meters which I use all the time but I saw another one on eBay which was sold as spares fairly cheap (£35) which arrived yesterday;  so I thought I would try and repair it today.

When you power it on there are no indicated fault codes,  but the issue is whatever mode of measurement the meter is in the display will flash  "- OL -" or overload.




I checked the main voltage rails and they seem ok;  I briefly looked over the relays but I think I will need to look more closely at the analog input side of things.

...later that afternoon

Well, after a shocking afternoon literally with this unit (lol don't ask!)   I managed to narrow it down;  so I just reheated a load of pins around the suspect area and it started working!   The calibration looks not too bad at all;  the sticker on it says the last calibration was 2016 so it should be good!

Btw, if your TIL117 chip is labeled IC307 then you have a later model 7150 (serials 300921 onwards), and if it's labeled IC306 then you have the older version;  there are some very subtle differences in the power rail circuit.



All in all very happy! :)



[later that afternoon... ;) ]



Well, the story didn't end there! it looks like I was somewhat premature in my celebrations!!, later that day it started glitching out again with the same issue!   I initially started to think it might be a component acting intermittently - that would have been a real nightmare to find and fix;  but what I found was after tapping the board in various places I found that it would fix itself, then fault again.

So, I carefully tapped each component and narrowed the issue down to near the front edge of the board;  after flexing the PCB very slightly one way I could make it work and by flexing it the other way it would fail;   so,  I started looking for any broken tracks on the board;  the PCB looked ok, so I started tapping each component,  then, all of a sudden I noticed the leg on a resistor had separated from the body - so I used my desoldering tool and took it out and replaced it for a metal film one, I tested a few resistors of the same value to get a better even closer match to the original one,  but the broken resistor was certainly the root cause of the overload issue.

I left the meter running most the evening and it was fine so I will leave it on for a few days to give it a bit of a soak test.








Sunday 15 July 2018

ESP8266 - Success!

A while ago I purchased some ESP8266 wifi modules with a view to add wifi capabilities to a project I'm working on.

The ESP8266 modules are very commonly sold and can be picked up very cheaply.

The module itself looks like this.
























These modules are 3.3 volts.  so I bought a USB to UART (3.3v)  module in order to experiment/test the ESP8266 from my computer.


The USB module looks like this once the ESP8266 is plugged into it.























Now there are heaps of examples of how you connect these up to Arduino boards or program them directly;  most of the Arduino examples use nice wrappers to get the ESP8266 up and running really quickly, but I wanted to use only the AT commands from my PIC microcontroller project to connect to the internet and pass data to a web server, and also get data back from the web server.

After a lot of messing about (I mean lots and lots of pain and hurt!) I found a nice workflow that worked for me;  that's not to say it will work with your module as these modules slightly vary between the firmware versions.

The process below describes using the ESP8266 with AT commands to pass data to a web server and then see the returned data from the web server.

For example, to send a web server the temperature read by your microcontroller.

eg.  http://myserver.com/mypage.aspx?t=120

What I did was create a c# console app to connect to the ESP8266 using the serial port and send it all the AT commands it needed to call a test aspx page on a web server which then returned some dummy JSON back to the module.








































The first thing I did was use Realterm on the PC to connect to the ESP8266 using the 115000 baud and slow that down to 9600,  if you need to do this you can do that by sending the "AT+CIOBAUD=9600\r\n" command;  this is so when the ESP is talking to my project my microcontroller has more time to process the data.

The command sequence that worked for me was..

1. AT+RST\r\n
2. AT+CWMODE=1\r\n
3. AT+CIPMUX=0\r\n
4. AT+CIPSTART="TCP","X.X.X.X",80\r\n
5. AT+CIPSEND=N\r\n"
6. (GET command, see notes)
7. AT+CIPCLOSE\r\n

Step 4, when I tried initially using "http://myserver.com" all I got from the ESP8266  "400 Bad Request"  so, if you're having issues try the server IP address instead.

Step 5, N is the total number of bytes sent in the GET request;  the only gotcha is to count these properly, in c# you can count the length of a string using strMyString.Length,  this will cater for the "\r\n" characters in the string.  i.e "/r/n" is 4 characters but it's 2 bytes long.

Step 6,  this to me was the odd part, in that the GET request seemed to fail but work on some servers;  now, I think the issue was the GET request headers didn't match the requirement of the web server.

The headers that worked for me were..

            url_get =    "GET http://myserver.com/mypage.aspx?t=120 HTTP/1.1\r\n " +
                            "Host: myserver.com\r\n " +
                            "Connection: keep-alive\r\n " +
                            "Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7\r\n" +
                            "Cache-Control: no-cache\r\n " +
                            "Accept-Language: de,en;q=0.7,en-us;q=0.3\r\n" +
                            "\r\n";


I may have over-cooked them a little but it seemed to work fine.;  you could play around and reduce them down to the minimum required by the web server.

Note: if you use HTTP/1.0 you don't require the "Host" header but if you use HTTP/1.1 you need to add that to your GET call.

Sending the commands it quite easy, but the tricky part is parsing the buffer of returned bytes in a way that triggers the next command in the sequence;  as you don't want to send the next command until the previous command has finished.   So, in the c# code I created a routine to check the serial read buffer for a particular string match;  the required strings I used for the step sequence above were..

Step 1.  If you use this prior to your calls you need to look for "WIFI GOT IP\r\n"
Step 2.  "OK\r\n"
Step 3.  "OK\r\n"
Step 4.  "OK\r\n"
Step 4.  "OK\r\n"
Step 5.  ">"  The > is the prompt for you to input the GET command string
Step 6.  Once the GET has completed you can look for the ":HTTP/1.1 200 OK" string, and within that buffer of bytes;  also within that buffer it will tell you how many bytes are returned;  this appears in the "+IPD," part of the string;  in my case, it looked like this..














Here you can see the string "+IPD,357" so this tells us there are 357 bytes in our buffer of returned bytes from the server, so you can then process through the buffer and pull out all the info you need.

I hope this helps anyone wanting to implement the ESP8266 in their project using only the AT commands.