Fixing Communication:

• Realized that the reason the ComMgr was not working was because I was trying to set properties which were DWORD with char*.
• DWORD is a unsigned long
• Set up a char[256] buffer on both the ComMgr side and the Arduino side to receive communications waiting to be decoded by type(command, response, state)
• Made a struct to char array method

Copying structs by bytes:

• At first I had it so that I was setting pointers for each struct and then casting the pointers into a char*.   Putting a & in front of the struct name returns the address of the struct eliminating the need for the extra pointers.  ex: char* test = (char*) originalData
• Another thing that was wrong was that I was getting the size by measuring the length of the character array.  This worked fine when I was using unsigned chars as data members but when I changed it to int things broke.  The proper way to do it seems to be sizeof(structName).  This has worked consistently no matter what the data types were including non-primitive string type.  (NOTE:  to use string with printf, the c_str() method needs to be called to format it properly.)
• sizeof(somePtr) seems to always return 4 bytes which I assume is the size of the memory address.  This may be why we were having trouble with sizeof because we were taking the size of a char*, if we were looking for a sizeof(char[]) it would have probably worked.  I tried to find the sizeof the contents of the pointer and it also said 4 bytes.  This might have been because the address it was pointing to was type int.  Either way it wasn’t giving the full size of the allocation which was 12 as found by sizeof(struct) which makes sense considering it had 3 ints in it.

ComMgr:

• It seems I can put the memory address into a void pointer so that send data won’t have to worry about what type it is.  The size will also have to be passed in because its hard to get the size from the pointer.
• The type needs to be identified so the arduino will know what to do with the data.
• Just noticed WriteFile is taking the address of the object and the next parameter is the size.  So I guess you can pass anything you want into it as long as you know the size.
• Have it working with the objectPtr and the size but its still only working with one byte.

Arduino

• Phil recommended that there be 4 states for the arduino:  Ready, Reading, Converting, and Writing.  We may need a 5th for executing once it has to actually do stuff but for communications this should do.  He also suggested putting 4 leds and indicators of each state so we don’t have to depend on the console to tell us during the debugging phase.
• Had to change the write method on the arduino side to print for whatever reason.  Have to look into why this suddenly stopped working tomorrow.

Start: 10:00

Com Console:

• Added StringEnum class because it is useful for keeping track of valid commands, responses, states, and serials.  Made it inherits from Printable so it will be able to print to console.
• Fixed the compiling errors in Command, Response, and State
• The methods for serial tracking as well as some other methods make these classes superior to the structs.

ComMgr:

• Realized I was still using the hard coded com port.  Making it so it can use a number that was passed in was a bit tricky.  CreateFile uses wchar_t which are not easy to manipulate with sprintf.  CreateFileA use LPCSTR which works with standard character arrays.  sprintf_s allows you to manipulate a standard character array as opposed to a char pointer array
• Added a resetPort method.  I think its better that you do it manually after making all the setting changes.  Also added changePort method.

char portNum[32];
sprintf_s(portNum, sizeof(portNum),”COM%d:”, _port);
hCom = CreateFileA(portNum, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

• Added run function so the send and receive methods didn’t need to be called individually.
• Still trying to find a tutorial for transmitting large objects.  Want to get this working before I start working on the ArduinoController and tweaking the command, response, and  state classes.

Notes On Using pointers:

• Phil showed me how to use pointers to copy a string byte by byte to a memory location allocated to integers.
• Create a pointer of type x(in this case a char*)
• Create another pointer and set it equal to this pointer.  This sets it to the beginning of the memory allocation.
• Create another allocation of memory to be copied to(In this case it was an array of 256 integers)
• Create another pointer and set it to the memory address of the new allocation.  Cast this to the type of the original data(in this case char)
• Start a loop which runs til it reaches the size of the original allocation
• Within the loop, set the contents of the new allocation equal to the contents of the old then increment both pointers.
• After the loop, set reset the new allocations pointer back to the beginning of the memory address.

Going to  try doing this with different data types, arrays, and structs tomorrow.

End: 6:30

Start: 10:45

Amplifier:

• Assembled the amplifier from sparkfun
• Edited a arduino sketch that might be useful for testing to see if A. how well the small amplifer controls the larger one and B. test both types of exciters
• Have not tested yet

ComMgr:

• Did a simple one byte pass-response to make sure everything was working thus far
• Added some test structures which will later be part of ArduinoController once I know its working
• Add command response and state classes but are not using them yet.  It might be better to use structs on the arduino side, so I am not sure if these will be used once everything is working.

End: 6:45

start: 9:15

ComMgr:

• added set methods for all the properties involving the com port.  The constructor sets the defaults and each change will close and reopen the port to save the change.
• port numbers can now be passed in
• Set up toString to reflect what it should look like once everything is working.
• Setup a basic sketch for the arduino so when i figure out how to send data structures I can test it.

End: 6:03

Start: 9:30

Com Console:

• Removed parts from the monitor class and put them into the ComMgr and ArduinoController classes.
• Useful Windows console functions: http://msdn.microsoft.com/en-us/library/ms682073%28v=VS.85%29.aspx
• Added sizing to the constructor so that the buffer and windows size will be appropriate for the application.  It seems that the buffer size width and height must be in a certain ratio in order to work properly.
• Got multiple lines to be overwritten using SetConsoleCursorPosition to set it to (0,0).  At first I used std::system (“CLS”) to clear the screen, but this was flashy so the other way is better.

• Added an output array to receive data to be printed from other classes
• added Printable class so there is a common type for the print method to use
• removed test data and methods
• sprintf is used to format char* to a char* without printing it

Notes:

• malloc is prefered over calloc not exactly sure why besides it having less parameters and something about calloc zeroing everything.  Will need this when sending large objects over the usb wire.

End: 6:00

Start:  8:30

Com Monitor Console:

• r is for carriage return which makes the next line overwrite the previous.  If the string is shorter in length it will not clear all the extra characters.  Padding the data with zeros helps make sure the string stays the same length.  It is important to resize your console to fit the whole line or it will scroll the first line and go back to the beginning of the second line.
• Need to make another class to handle actual communications instead of having it in the monitor class as it is now.
• getch() halts the loop so its not good for user input in this case.  I forget which one to use instead.

Notes for ComManager class:

• Init should be moved into this class
• sendData and recieveData should also be moved and changed to accept null pointers and a size.  This should be easy on the sending side but I am not sure about the receiving side unless the size is always the same.  I will have to see if there is a way to get the size of a incoming package so that the method knows how much its receiving.  One possible solution, if nothing else, might be to put the size in the first byte and have two ReadFile calls one to grab the size and the other to grab the remaining data using that size.
• Need to read this tomorrow to get an idea of how calloc is used to make a generic array:  http://www.cplusplus.com/reference/clibrary/cstdlib/calloc/
• Need to look up more information on void pointers.  They seem to be typeless pure memory and can be cast into anything.

End: 5:00

Start: 9:30 am

Examining new components:

• The 13mm exciters are the perfect size but may not be powerful enough with only a 1 watt rms
• The 25mm exciter is a bit bigger and heavier then I initially thought but has a 15 watt rms which may be needed.
• The base shaker seems to be a good size but weighs a bit more then I thought it would.  This also has a 15 watt rms
• Need amplifiers to test the bass shaker and higher powered exciter.  Will test the 13mm tomorrow.

Incorporation of COM to RCS:

• Set up the read, write, init functions
• Am trying to figure out how the DataDictionary works as well as where changes will need to be made for the simulaton to read off the new arduino controlled entries as opposed to the phidget inputs.
• Forgot to add DWORD n and HANDLE hCom are both required for com communication
• Not sure if there is a way to scan com ports for specific devices.  Currently its hard coded but may need to be manually entered in case port changes.

Com Monitor Console:

• Copied relevant functions into a new project to eliminate some of the complexity as Phil asked.
• Outputs will be printed on one line which will not scroll.
• Found the proper sketch for testing this and renamed it “ComTest”  so that I don’t get it confused again.
• Will finish this tomorrow

End: 6:00 pm

• Passing multiple bytes of data worked but is a little hard to tell if its going in the right places with a scrolling console screen
• Brought in the dependent classes from RCS system into the sandbox so that the test class will function more like it will in the final product
• Working on adapting it to the RCS controller format and displaying output on an openGL overlay so I can see everything is working clearer.

• Sketch should be able to send and receive multiple pieces of information from the structs
• Added initialize/stop commands
• Working on the PC side so I can test the sketch

Arduino Sketch:

• Found out that the write command need an array of type uint8_t.  For some reason this isn’t labeled in the documentation.
• Changed the basic structure to have the appropriate preProcess(), decisionProcess(), postProcess()
• Changed it so loop doesn’t start unless initialized is true.
• add sendData and recieveData methods that work with the command, response, output structs

Arduino Communication:

• Currently at the stage where I can start integrating the sandbox code into the existing RCS system.
• Realized that because we are going to use the Arduino as a strain gauge reader, there will need to have a second piece of data feeding this information to the computer.
• I am going to start the communication integration by trying to get the test stick to move one of the “fingers” in the 3d simulation.

Speaker-amplifiers-shakers:

• I am not sure if 1 watt is good enough for the tactile sensation we are trying to get.
• Somethings to experiment with

1. 15W 25mm transducer:  http://www.parts-express.com/pe/showdetl.cfm?Partnumber=300-377 (If we need more power these are what we need)
2. 1W 13mm transducer: http://www.parts-express.com/pe/showdetl.cfm?Partnumber=300-379 (It maybe that 1 watt is enough if we use a transducer instead of a speaker)
3. Bass Shaker: http://www.parts-express.com/pe/showdetl.cfm?Partnumber=300-388 (For an added thump on initial contact)
4. relatively low-powered 38W peak amplifier: http://www.sparkfun.com/products/9612 (Not entirely sure this is the best bet yet.  It would be nice to find one that can be digitally controlled but it might be possible to drive this with our 1 watt amps as a preamp.  It could also be possible to replace the trim pots with 10k potentiometers.  The problem with the i2c 10k pots I found before is that they are not addressable.  If we do go with i2c potentiometers, the response time would be almost instant as opposed to the minor pulsing delays of our 1 watt amplifiers.  It is probably best to drive them with a preamp, so that the max power is hardwired, protecting the 15 watt transducers and shaker.  This limit can also be controlled by reducing the input power though.)

• I am going to look a bit deeper into amplifiers before sending you this list to order.
• Sent e-mail for order

Monday Arduino Communication:

• Serial.write(buf, len)  does the same thing for the arduino as the windows WriteFile allowing to send arrays.

• Was not able to get the serial class working but was able to get it working the standard way.
• Com port was not initializing properly.  Copied the working code from my i2c sandbox and it seemed to fix the problem.
• Was able to send data and receive a response.
• Going to attempt to pass the data as a struct.

• Still having problems with communication between computer programs and the arduino.
• This website explains some of the problems with using the standard win32 methods:  http://www.codeproject.com/KB/system/serial.aspx
• This class may help: http://www.assembla.com/code/dc_pts/subversion/nodes/serial_src?rev=205
• Sketch side works when I use the arduino serial console so its just a matter of the program not sending/receiving data properly.