C# MVVM Where Does the Service Layer Sit?

I am attempting to develop a little program which will communicate with a device on a serial port. The program will be responsible for formatting user entered data and reading and presenting values received by the device. I am pretty new to WPF and MVVM and have achieved a basic understanding of the whole databinding / XAML mess (I think).

Currently my understanding goes something like:

View: UI only stuff. Binds to ViewModel.
ViewModel: Takes a model or various properties of a model and presents them in a way that the View can understand. Also provides a way for the view to modify the model.
Model: The data the UI presents and modifies.

Now I am at a loss as to what provides Models to the ViewModel such that the application as a whole is aware of changes to Models.

The Model currently looks something like the following. My device takes calibration records and can read back all the calibration records.

public class Device : ObservableObject
{
    public ObservableCollection<CalibRecord> CalibRecords { get; set; }

    private SerialPort sp;

    public Device(SerialPort port)
    {
        this.sp = port;
        this.CalibRecords = new ObservableCollection<CalibRecord>();
    }

    public void WriteCalibration(CalibRecord record)
    {
        /* Write a calibration record to the device */
    }

    public void ReadCalibration()
    {
        /* Read all calibration records from the device and update CalibRecords */
    }
}

I am struggling for a place to put this guy so that it can be accessed by the entire application. Currently I instantiated it in the main window's ViewModel but then it can't be accessed by other ViewModels unless I inject it into the constructor. This is fine for a couple classes but gets unwieldy quickly the more classes a ViewModel needs.

Perhaps this is what the so-called "business logic" or "service layer" is. Can you help me understand where to put the business logic in an MVVM app? Or, do you guys have some examples I should look at that focuses on the whole application (particularly the business logic) and not just the MVVM stuff?

Your understanding of MVVM is correct, but the "textbook description" doesn't account for services. Typically this is done with dependency injection (DI). Define an interface, IMyDevice and implement it in a MyDevice class. Then register it with your DI container IMyDevice -> MyDevice. By using a DI container (properly) you'll also take yourself out of the VM construction picture. You would have a VM something like:

public class MyViewModel : ViewModelBase
{
  public MyViewModel(IMyDevice myDevice)
  {
  }
}

to get an instance of the VM, you would do:

theDIContainer.Resolve<MyViewModel>();

and it would new up the MyViewModel class and automatically resolve and pass in the IMyDevice instance for you.

There is a lot more to DI then I covered here... just a basic 10,000 mile high answer to your question. Read up on DI and see how it comes into play with MVVM.