NASA Prediction: Hướng dẫn lấy dữ liệu bức xạ lịch sử theo tọa độ GPS từ vệ tinh NASA.
Khi thiết kế hoặc đánh giá một hệ NLMT, dữ liệu “trung bình năm” kiểu chung chung thường gây ảo tưởng. Cái bạn cần là bức xạ theo đúng tọa độ và chuỗi thời gian đủ dài để thấy mùa, thấy năm xấu/năm tốt. NASA POWER là một nguồn dữ liệu phổ biến vì: truy xuất theo lat/lon, có daily/monthly, và phù hợp làm baseline.
- Sau khi đọc: bạn lấy được dữ liệu bức xạ lịch sử theo GPS trong vài phút.
- Sau khi đọc: bạn biết cách kiểm tra đơn vị để tránh “kWh/m2/ngày” bị hiểu nhầm thành “W/m2”.
- Sau khi đọc: bạn có mẫu log để lưu baseline cho O&M.
1) Chốt đúng mục đích trước khi lấy dữ liệu
- Thiết kế sơ bộ: dùng monthly để nhìn mùa, nhanh và nhẹ.
- Baseline & phân tích PR: dùng daily để có độ chi tiết theo ngày.
- So sánh địa điểm: cùng 1 bộ tham số + cùng khoảng thời gian để so công bằng.
2) NASA POWER: tham số nào dùng cho Solar
Tham số hay dùng cho PV là bức xạ mặt trời xuống mặt đất (surface downward shortwave radiation).
Một biến rất hay gặp trong NASA POWER là ALLSKY_SFC_SW_DWN (all-sky = có xét mây).
3) Ví dụ endpoint (daily theo tọa độ)
Bạn gọi API theo dạng temporal + point. Ví dụ daily cho một điểm:
https://power.larc.nasa.gov/api/temporal/daily/point?parameters=ALLSKY_SFC_SW_DWN&community=RE&longitude=106.7&latitude=10.8&start=20200101&end=20201231&format=JSON
Nếu muốn monthly thì thay /daily/ thành /monthly/. Điểm quan trọng là:
lat/lon đúng, start/end đúng định dạng, và format bạn cần (JSON/CSV).
4) Checklist kiểm tra dữ liệu để không sai đơn vị
- Đọc metadata: trong JSON thường có phần mô tả đơn vị/nguồn.
- So logic theo mùa: miền Nam VN thường nắng cao quanh mùa khô, thấp hơn mùa mưa.
- So với thực đo: nếu bạn có logger/pyranometer, lấy 7–14 ngày đẹp trời để đối chiếu thô.
- Đừng trộn: daily (kWh/m2/ngày) với hourly (W/m2) khi vẽ chung trục mà không đổi đơn vị.
5) 4 pattern hay gặp khi dùng dữ liệu lịch sử
Pattern A: Chọn sai tọa độ (lệch vài km vẫn sai)
Dấu hiệu: bức xạ “đẹp bất thường” so với cảm nhận thực tế.
Nguyên nhân: lấy tọa độ ở trung tâm huyện/thành phố thay vì tọa độ đúng của site.
Xác minh: lấy lại GPS tại mái/nhà máy và so 2 điểm.
Pattern B: Dùng monthly để bắt lỗi ngày
Dấu hiệu: muốn giải thích 1 tuần PR thấp nhưng chỉ có dữ liệu monthly.
Hướng xử lý: chuyển sang daily cho giai đoạn đó để có độ phân giải đủ.
Pattern C: Nhầm đơn vị
Dấu hiệu: vẽ đồ thị, thấy bức xạ “mấy trăm kWh/m2/ngày”.
Nguyên nhân: coi daily (kWh/m2/ngày) như W/m2.
Xác minh: kiểm metadata + đổi thang đúng.
Pattern D: Lấy dữ liệu quá ngắn
Dấu hiệu: kết luận site “ít nắng” chỉ vì 1 năm mưa nhiều.
Khuyến nghị: tối thiểu 3–5 năm để thấy biến động giữa các năm.
6) Bảng ưu tiên dùng dữ liệu (thực dụng)
| Mục tiêu | Temporal | Gợi ý thời gian |
|---|---|---|
| Thiết kế sơ bộ / so mùa | Monthly | 5–10 năm |
| Baseline PR / phân tích vận hành | Daily | 1–3 năm + đoạn cần soi |
| Đối chiếu cảm biến tại chỗ | Daily | 7–30 ngày |
7) Mẫu log hiện trường (bắt buộc)
Site: … Tọa độ (lat,lon): … Nguồn dữ liệu: NASA POWER Temporal: daily/monthly Parameters: ALLSKY_SFC_SW_DWN (và các biến khác nếu dùng) Khoảng thời gian: … → … Đơn vị theo metadata: … Kết luận sơ bộ: mùa cao … | mùa thấp … | năm bất thường … Ghi chú: dùng làm baseline PR từ ngày …
8) An toàn & giới hạn
- Dữ liệu vệ tinh/mô hình là baseline, không thay thế đo bức xạ tại site khi cần nghiệm thu hiệu suất nghiêm túc.
- Khi dùng cho dự báo tài chính, nên dùng thêm nguồn thương mại/địa phương để cross-check.
Tham khảo tổng quan: NASA POWER Data Services và hướng dẫn API tại power.larc.nasa.gov.