top of page
Search

Week 26:

  • Writer: Will Davis
    Will Davis
  • May 3, 2019
  • 2 min read

Problem:

Since the last blog post, there have been some errors revealing themselves in the system.

When the log files are trying to be completed, their data keeps getting changed and because the stationHistory has been wiped, stations will start uploading data again.

Solution:

Sending a custom message with just the carrier number and station name so callback can rename the file to be completed. Once the blank message is published, a stationFinish boolean is set to True so the next lines don't try and add the data to the file.



I spent the rest of this week once again focused on trying to invent a way to send all the data from node node to another in the quickest, most efficient way possible.

To start with I was looking at sending the completed receipt data by reading in the file and sending each line over custom message.

Testing this idea was hard in the main script because there are so many unknowns. I created a test script that could read in a file and send it's contents over ROS which worked quite well. Implementing the test script after debugging was a lot easier and it seemed to work most of the time. This could be a different matter when I try and run it on a Raspberry Pi.


Improvements:

In the emitter() function that broadcasts the block's hash, I've included a variable reading in the amount of files in that node's directory as a salt hash. This means that the node is hashed with an extra number in it. I did this in being preemptive of the rewrite function when I eventually solve it. When a node is fully rewritten with all the correct data, the amount of files contained in it's directory should be the same.


I've ended this week still without managing to crack rewrite function, however, I did manage solve another problem which is as follows..


Problem:

One of the objectives talks about the end user being able to reveal the blockchain of their product away from the factory so they have proof of authenticity.


Solution:

I created custom QR Codes that contained a web link to a file server running on one of the Raspberry Pi's. My original idea was to somehow create a QR code from the raw blockchain receipt data, therefore, not having to access a server to retrieve the information. When I created the first QR code as a test, I decided wholeheartedly that this was not the best solution.

This is obviously totally impractical, the slightest bit of dirt or the wrong lighting could make this not work.

Upon the decision not to do it that way, it also made more sense to use a file server for security purposes.


In the end, creating QR codes with file server links made a lot more sense, with a much more practical QR Code.

The next steps for this are when a receipt is completed, the file is copied across to the file server directory to reveal the blockchain automatically.


 
 
 

Recent Posts

See All
Week 25:

A few key problems were solved this week: Problem: When the carriers go round the MES conveyors, the carriers wait to be taken across to...

 
 
 

Comentários


©2019 by William Davis - Engineering Major Project. Proudly created with Wix.com

bottom of page