There have been several significant updates to Mavericks, so the first step would be to run software update and get the OS and any firmware updates installed. Next, you can troubleshoot the issue as follows:
System log
Look at the error messages relative to the blued daemon:
grep blued /var/log/system.log
(this is a command to type within Terminal).
Check in this system log if you don't have connexion attempts from an unknown
Bluetooth equipment. To be able to detect the intruders note your own
Bluetooth address within:
System Information > Hardware > Bluetooth
ex. :
Hardware Settings:
Address: A8-BB-CF-9B-07-D8
Manufacturer: Broad…
Battery check
This system log won't display any information about the battery level.
You should check it with Alt ⌥ + Bluetooth menu bar icon:

Interference check
For this interference analysis, install iStumbler and run it.
If you are in such a full of interferences environment, put away the other Bluetooth equipments, turn off your Trackpad, wait 30 s,
turn it on. If your problem is the result of Bluetooth interference, this might recover its system connectivity (Bluetooth equipment rotate through the frequencies to use on the same channel than the 802.11g. When 2 of them are on the same channel, they are jaming each other).
You may also analyse the behaviour of your Bluetooth connexion in realtime with MacOS X standard tools:
System Preferences > Bluetooth
press Alt ⌥ to display the actual level of Bluetooth signal:
And to go further, open the gear drop down menu to select Monitor Connection RSSI to monitor the connection quality:

Restart the daemon
If you are able to start a Terminal or access your system through ssh, then you can easily restart blued with these few commands:
ps ax | egrep '[ /](PID|blued)'
/usr/bin/sudo launchctl stop com.apple.blued
ps ax | egrep '[ /](PID|blued)'
The second ps should display a new process ID, confirming you that
launchd restarted blued correctly.
If blued doesn't restart (PID stays the same) then you are facing a more serious problem to investigate, and you will have an harder kill:
ps ax | egrep '[ /](PID|blued)'
/usr/bin/sudo killall -c blued -KILL
ps ax | egrep '[ /](PID|blued)'
But this isn't a good sign at all. This means that blued was stucked within a system call beyond any possibility to deal with a signal. This
is most notably the sign of a bug within the Bluetooth driver or kernel extension.