An overall good week. UK dogs made a good return with 0.084%. Looking at the chart, the sharp drop early in the results was on one runner in a very active market – 46 settled bets in less than 3 minutes. Of those, three backs were placed around 5.8, followed by a fast drift against which my bot chased and partially matched at 6.2 and 7.5, then finished on 8.

The Aus chart looks good but holds a warning. The two big wins were due to errors. The first was a Lay placed when there shouldn’t have been. The log shows a Lay placed with no Fill/Kill or Tick Offset. My bot only places these during greening so I can only think a matched bet was showing as unmatched and then changed afterwards, as my records show all as matched.

The second was a Lay placed 15 seconds after the start time. This should not be possible as my bot jumps to next race at -1 second. I can only assume that the connection was hanging and this had an effect.

I think it’s safe to say that after a number of errors recently that have left me with a profit, I will soon experience a loss from an error. As they tend to be Lay errors, I assume the loss will be large.

As requested by Betfair Pro Trader, here are some charts.

The first is the best continuous data I could get together, covering over 6000 UK greyhound markets from 28th September 2015 to 31st January 2016. This covers a lot of changes with the settings and even trading rules such as allowing multiple open bets on one runner. (Ignore chart title, it is from 28th September)

I have mentioned before that the AUS horses ran a lot tighter on the settings and that early in January I changed the UK dogs to the same limits. So below is the period 3rd to 31st January, cut from the above chart. This period saw an increase greater than 1.5 times the previous 2 periods combined. So far this confirms the settings are now more beneficial despite my concern they may have had a negative impact on activity.

Another week and the swing from Aus to UK being more profitable has continued. The UK chart is very pleasing on the eye. The Aus chart not so. Another day was missed, Wednesday, which is quite a busy day on the Aus horses judging by the number of tweets  I get from @Betfair_Aus. Apparently this is due to missing info from the Aus API when market refresh is triggered in Gruss. I must get round to adding more code to try and prevent this. The large loss was another one of those things, no errors or missed bets, just quite a few losing trades in a row on one market.

With reference to my last post about costs, Januray’s P&L was £32.97 pre costs and £17.87 after. So I achieved my goal of not being a loser.

I’ve been monitoring my computers energy use since October and on average it costs £9.10 per month to run (this includes UPS). Added to the Gruss subscription, that’s £15.10. I’ve looked into putting it on a virtual server (VPS) but it’s a bit costly at the moment. Although monthly fees for a windows setup can be found for less than £9, adding Office to be able to use Excel pushes the price up.

When my own bot is running OK, I should be able to move to a VPS, reducing my costs. There are other benefits to this, such as faster connection and better up time. Also being able to access from anywhere would be good. I could access my own computer remotely but I’m sure that would interfere with the bot’s response time. Anything I do seems to effect it, even sending a small file causes Gruss to pause.

The data collection is working perfect and isn’t having any impact on the trading, by which I mean it isn’t slowing it down at all. I use timer to track code execution times.

The issue is file size. At the end of each day’s trading, the data is saved to a new file. These are around 150mb in size. I keep all my trading stuff in cloud storage, which has its limits (capacity). It got me thinking, firstly to store locally, secondly, how to make use of it. This takes me back to where I started with data collection- what to do with it.

It’s all about analysis. If I work out the process of analysis, find the relevant data points I need to monitor, I can perform the calculations live and save the results only, rather than everything.

Having a good few days worth of data will be useful for testing but I don’t want to have endless reams of stuff I might never go back to. So once I’ve got a couple of gigs stored, I’ll stop the collection and start the analysis.

The big story from last week was missing 3 days of trading on the AUS markets. 2 were down to software malfunction, it’s being investigated. The 3rd was a coding issue.

Sometimes it doesn’t matter how many times you test the code, step by step, forcing values in, it still gets stuck when let loose in the real world. It worked great collecting data but I reworked the process for better efficiency and missed a single line. This wouldn’t have been a problem if I’d had ‘on error resume next’ in the code but I don’t like using that if I can help it, especially when the code is new and I really want to know what the errors are. (A good place to use ‘on error resume next’ is when scraping data from a website, as any errors on the webpage could stop the program dead, even if it’s just a typo or faulty link). So when my code saves all the day’s data to a new file, it deletes it from the running bot. This left nowhere for the current events data to be stored and just hung on a runtime error. Easily fixed though.

The UK dogs produced really good results, greater than 0.1%, which I see as good. And a smoother chart than in previous weeks.

The AUS horses, as discussed, was a mild let down. The traded results were a bit more choppy than previous weeks. The large win at the end was due to a partially matched lay, this time going in my favour.

I’ve been testing the data collection code and trying different ways of reading and presenting it.The chart below is an example of what can be produced from the data.

This data, from a UK greyhound race, is for one runner and covers the last two minutes of trading before the scheduled off. The blue line is the LTP (last-traded-price). The red and green lines are the WOM (weight-of-money) values on each side. On this particular chart there appears to be some connection between periods of WOM in one direction and the trend of the LTP. From the left as LTP is falling, WOM is pushing in the downward direction (red line). Then from the centre, as LTP is rising, WOM is pushing upward (green line). More testing required.