Hardik,
The short answer is that sampling should all begin at the 0th second, but does not always contain physiological data at this point.
There are various reasons related to hardware, software, technician process and patient setup that can result in physiological data not being recorded at the 0th second. Even if there is no physiological data being captured all channels will begin recording simultaneously and display either a value of zero or a wide range of values caused by artifact (caused by hardware/setup factors.) Looking for start times based on sampling rates must also note that sampling rates can vary between EDFs, cohorts and channels contained in the same EDF (ex. EEG sampled at 256 and ECG sampled at 512).
Hello Hardik,
It is very common for studies to contain raw ECG and EEG data before the first epoch marked as sleep. This is important in PSG because the time between a participant beginning their "time in bed" (which can occur at epoch 1) and sleep onset is an important statistic for various calculations. Some studies where participants have trouble initiating sleep can contain minutes or hours of ECG and EEG data before any sleep is scored.
During many PSG setups all leads (including EEG and ECG) are fully attached before beginning recording and can result in sampling of both starting simultaneously. In other cases raw data can be recorded during hookup for troubleshooting, and result in ECG (which is commonly attached first) appearing on the recording well before any EEG data. I would recommend using denoted "recording start", "lights off" or "start time in bed" notes when available as opposed to epoch 1 (e.g. the time between epoch 1 and "lights off" may contain raw data, but is not considered a usable part of the PSG).
I hope that adds some clarification.
Stephany, I just checked the EDFs for 300721 and am failing to reproduce this issue. Both the baseline and followup EDFs for 300721 end at the expected times (5:56:38 and 6:03:13 respectively) and both show a "duration of data record" of 1 when I look at the headers. Can you clarify what you are seeing as the stated duration in the data records? Were the EDFs causing the problem downloaded before Sept 4? Some EDFs were reprocessed for the Sept 4 posting so there is a possibility that the current versions (that I downloaded and checked) are free from this duration bug. ~michael